Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘css

Frustrations in Developing Mobile Applications

with 14 comments


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?


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 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.


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 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.


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

Sage 300 ERP Web UIs and CSS

with 2 comments


Last week I blogged about using MVC to program the new Sage 300 Web UIs, this week is an update on how we lay out the forms for the new UIs. I blogged on the previously here; but, this article is quite outdated now, everything mentioned will still work, it just isn’t the preferred way of doing things. This week’s post is an update on how we are now laying out forms and applying CSS to best effect.

In the early days of the Web there was only HTML. HTML was designed to structure content, mostly for scientific papers. Over the years, HTML was extended to allow more content types and to add tags for formatting. HTML has always had a set of table tags which were intended to display tables of numbers, usually produced by various scientific experiments. Clever web designers then figured out how to layout quite sophisticated layouts by using these table tags, by putting tables inside other tables and such. These ideas were extended for a while until it was finally realized that HTML was getting over-burdened and that we really needed to separate the content from the formatting. This was when Cascading Style Sheets (CSS) were introduced.

The intent with CSS was that people would stop using various formatting tags in HTML (like the font tag) and would instead do all their formatting in the CSS. Then in HTML tags would only be used to specify content like paragraphs, sections, copyrights, etc. Then tables would only be used to represent proper tables again. However for compatibility all the old HTML tags had to be left in place, so now we have a situation where you have to know which tags in HTML to use and which not to use, because you should use CSS. If you want to layout your pages using CSS then you need to use the HTML div and span tags which don’t do anything except give CSS a way to control your layout, then you want to avoid the older layout tags like the table ones.

CSS is used both for layout and for controlling the detailed look of content elements. This blog posting is concerned with the CSS features to do with layout and not the features to control things like color and font style. That would be a large blog posting in its own right.

GWT provides access to both the HTML way of formatting and laying out pages as well as the CSS method of laying out pages. Some GWT layout controls like the grid, horizontal panel and vertical panel wrap HTML table tags. Some GWT layout controls like the flow panel and simple panel wrap HTML div tags. This can be tricky since the GWT documentation isn’t always clear on what DOM elements are being created by a given control. But generally if you aren’t laying out the form via CSS then use all the panels, if you are using CSS then you will only use a couple of GWT’s layout panels.

CSS lets you control layout in a liquid or flowing manner, or control the layout by using fixed absolute placements and sizes (usually in pixels). Generally we want a liquid layout, so that our pages can be resizable and automatically adapt to different screen resolutions and still look good as various parts are hidden or shown depending on application options.

If you read a book on CSS (and there are many excellent examples), you quickly notice that all the terminology is from typography and magazine layout. Sometimes it takes a bit of getting used to this, so you can see past the terminology and apply the ideas to the layout of your form. This just takes a bit of patience and time to get used to.

How Sage 300 Uses CSS for Layout

The main way that you control form layouts with CSS is through controlling things in HTML div tags. These were designed to have CSS attached to them and then you move them by floating them around and controlling their size and dimensions. First let’s consider a simple form with labels, textboxes and sometimes a menu icon to the right of the text box. Since we want to control the placement of each control we wrap it in a Simple Panel and place them in flow panel’s as the diagram below indicates:

We then build up rows of the controls we want. Then to break each row we have a simple panel with the clear style which then acts as a line break. As you can see from the diagram this leads to a fairly simple setup, but it doesn’t look like it will lead to much of a page. But this is how we lay it out in HTML, and then we will leave it to CSS to make this look pretty.

To build up more complicated layouts we nest these. So for instance if we want a two column display then we put two flow panels side by side and then build the above idea in each one. The below diagram shows how this level is setup:

The labels in the diagram are the styles applied to these flow panels. Now you might think that we are just doing what we did with HTML tables at this point, having to nest them in complicated ways to get our effect.  This is true to some degree, but we have more control. For instance in a table control if you want to hide one cell, then the cells below will not move up to fill it, because this is a logical table. Cells only move up if you hide an entire row of cells. In the CSS scheme things will move up whenever there is room (unless you tell them not to), so this keeps forms much cleaner looking when parts are removed.

Another thing that controls layout is the CSS box model. This is the mechanism where you can put margin, padding and border around any element that you apply CSS to.

These elements give you a lot of control around how you position elements on the page. If you make the left padding of a flow panel large then you push the things contained in it right, etc. How to really control the fine details of layout using the box model can be a bit confusing at first, but it is easy to look for examples on the web that show all the tricks.

In the Sage 300 ERP SDK we provide a SwtDefault.css that contains all the styles you need. Then if you create your declarative layouts as we indicate and follow our style guidelines, you should get nice looking adaptable screens fairly easily. So basically it contains a lot of styles that are intended to be applied to simple and flow panels. These are intended to setup various page design patterns that we document in our UI guidelines. They then have the various floats to format the rows and to setup multi-column displays. They also include all the correct settings for the box model so that everything is spaced and sized correctly. This gave our interface designers a very fine grained level of control over the look and placement of all the controls.


Hopefully this gives you a flavor for how we are using CSS to layout our forms. CSS is a large topic, but for an application developer it’s really a matter of having a basic understanding so you can use the palette of styles that are provided by default effectively. If you are really advanced you can change the CSS files to completely change the way Sage 300 screens look.

Written by smist08

November 5, 2011 at 4:18 pm

Accpac, GWT and other Web Technologies

with one comment


Last weekend I travelled down to Seattle, Washington for a nice getaway weekend and to see the Science Fiction exhibits at the EMP.  Then on Monday night I gave a presentation to the Seattle GWT Users Group on Sage ERP Accpac’s use of the Google Web Toolkit (GWT) in our 6.x product line. I found the group to be really knowledgeable and they asked great questions throughout the presentation. I learned a lot from the meeting and from chatting with the various people attending. Definitely very worthwhile. I previously blogged about Sage ERP Accpac’s use of GWT here.

Games on GWT

id Software makes many of the most popular first person shooter games including Doom, Quake and Castle Wolfenstein. Their lead programmer is John Carmack who is a legend in the gaming industry. One of the cool things they do is release the source code for some of their older games. They also port their games to various platforms, so often there will be an OpenGL version as well as a proprietary version, and perhaps a version ported to Java as well as the original version in C. A key metric of new computers, operating systems and devices has been how well they run the open versions of these games. I was really impressed when Google ported Quake II to GWT. Seeing Quake II work really well in the Chrome browser just using HTML5 was really really impressive. To me this really showed the power of the Browser as an application development platform, that if you could get Quake II running with a reasonable frame rate, then getting ERP screens going should be a piece of cake.

Of course the times have changed and Quake isn’t the most popular game anymore. So I was really surprised to see the latest hit game, namely Angry Birds ported to GWT. Angry Birds originated as an iOS game that has been hugely popular on iPhones and iPads. Angry Birds has perhaps more than anything been the killer application that has driven people to these devices. Of course Rovio wants to capitalize on the success of the iOS game, by porting it to other platforms. The easiest way to do this is to port it to HTML5 so it will work on all platforms, rather than doing separate ports for Android, Windows, WebOS, Blackberry, etc. For some more details on the porting of Angry Birds to GWT, have a look at this blog. GWT seems to be becoming quite a good technology for developing HTML5 based games. Many people are predicting that doing separate ports to all the mobile platforms, desktop platforms and game consoles is already way too expensive and most game development houses are looking to solve this with HTML5. This won’t work for all games, but it will work for many of the popular classes of games that are so popular these days.


Cascading Styles Sheets (CSS) are a fundamental part of the Web today. All Web Sites use CSS to some degree to control their appearance and layout. Knowing and using CSS is a fundamental skill required of all Web developers. However CSS can be quite hard and quite tricky. When we use GWT it solves the problem of JavaScript differences between the browsers and does a really good job of this. However GWT only makes sure that you can use CSS, it doesn’t help you write it and it doesn’t shield you from Browser differences. There is a CSS version 3 standard that everyone purports to support. However support for this standard is variable across the different browsers. Generally for what we are doing, things work great in Firefox, Safari and Chrome. But then they break down in IE. Plus the support is quite variable across different versions of IE and since MS doesn’t support all versions on all their operating systems, software vendors get stuck supporting several versions of IE, all with different CSS bugs and omissions.

Fortunately we discovered an open source project called CSS3Pie which fills in many of the gaps missing in various versions of IE’s CSS3 support. What CSS3Pie does is recognize the version of IE and when CSS is processed, if IE can do it correctly then it lets IE handle it. But if IE can’t do it then it performs the operation for IE using JavaScript. I hope the Microsoft programmers on IE’s CSS handling team see this project and feel bad seeing how others implemented what they claimed was too hard.

When we started moving our Accpac screens to the Web we did all the layout using DOM layout nodes (which are abstracted as layout controls in GWT), but over time as we’ve become more proficient in CSS and now that we don’t have to worry so much about IE’s deficiencies, we are actually doing much of our layouts using CSS. This tends to lead to finer control than you can obtain using layout nodes so we can refine our look and feel to a higher level.

Asynchronous Programming

One of the reasons we chose GWT as the foundation for our new Web UIs, was that GWT was all about AJAX fundamentally from the start. AJAX wasn’t tacked on later to a system that was really from the Web 1.0 days. The support for AJAX in GWT is really great; but, our programmers coming from the VB world sometimes have trouble wrapping their heads around it. One of the fundamental differences between programming for the Web versus Client/Server is the issue of latency and how this accumulates as messages move across the Web. As the Web has progressed we now have tremendous bandwidth; so there are services that can stream a 4Gig movie to you in less than half an hour. However if you need to send a message across the Internet and wait for a response, it might takes 100ms which is still really fast, as long as you are only doing 1 message. If you do 10 messages then it takes a second, 100 takes 10 seconds, etc.

Programmers used to client/server programming on a LAN that probably spans only 1 building, don’t have to worry about this. Their latency is less than 1ms and they can make 1000 calls to the server without annoying users with a delay too much. As client/server programmers move to the Web there is a strong discipline required that if you have a process that require 10 server calls, then it must be re-factored to only require 1 call. Within our SWT framework, we make it easy to make 1 call, but don’t provide any help to string together multiple calls. This is intentional. Then we provide a good framework for our programmers to move “bad” code from the VB UIs into server classes where they can make many calls without penalty.

Perhaps the point here is that you need to do this independent of the Web programming framework. GWT has good support for AJAX, but it falls to the application programmers to use it correctly and this mind set change is really a function of moving to the Web rather than the choice of Web technologies.


Sorry if this blog posting is a bit disjointed. This is really just some thoughts based on discussions at the GTUG meeting on the pros and cons of GWT as well as adapting to other general Web programming models.

Written by smist08

September 24, 2011 at 10:21 pm