Anyone willing to help out on a small project?

[Spacerat]

I have server desktop apps that needs to talk to an Android tablets. The server apps record weights, tag numbers from devices at work stations on the factory floor. The factory is a clean environment so cannot put PCs on the floor.
I need to display user feedback like weight, tag number, status to the users, so the thinking is to use ruggedised android tablets for this (I considered R-Pi3 and monitor,but too much effort and not rugged enough). It means that the server apps need to push info to the tablet for display only. I would like to keep the tablet deployment free as far as possible. Not wanting to install an app if it can be helped.

So the idea is to create a webpage on the server that displays all the work stations after the tablet powers up. Then the user selects that link corresponding to that work station/function and the relevant webpage opens. This webpage will use websockets/SignalR to receive realtime info from the server apps. Must not have to poll.

The server apps are done (in C#), but the tablets as remote displays need to be done. So likely some HTML/JS and maybe some C# work.

Anyone interested in helping? Freelancers and night-time workers welcome. If needed you only need to do one and then I can copy/paste for the other functions (each display is different).

 

[[)roi(]]

I really don't understand the aversion to installing apps?

 

[Nerfherder]

I really don't understand the aversion to installing apps?

Has to be tailored to the device.

Much easier to use a mobile friendly web page.

 

[Swa]

I don't understand the aversion to polling. Can be done with Ajax which is much easier than sockets which would probably require apps.

 

[Spacerat]

Not averse to apps. My 'feeling' is that zero deployment is first prize from an operational support point of view. But I may be wrong. If I do go the app route then Xamarin is the best choice as the rest is coded in C#.

I am not completely averse to polling. But it will need to be 1sec freq. Which is not a real issue. Polling is MUCH easier from the client side, but more complex on the server side. It's not a web app. It's apps that integrate various devices on a factory floor. But in the past I have used polling on IE sick and the page flickered a lot when the DOM was updated. Not sure what the device browser will do.

To me a websocket is the most elegant...

 

[[)roi(]]

Has to be tailored to the device.

Much easier to use a mobile friendly web page.

Don't see why's that a problem? The limitations of web tech are far greater hinderance + don't just assume web tech shields you from that.

 

[[)roi(]]

Not averse to apps. My 'feeling' is that zero deployment is first prize from an operational support point of view. But I may be wrong. If I do go the app route then Xamarin is the best choice as the rest is coded in C#.

I am not completely averse to polling. But it will need to be 1sec freq. Which is not a real issue. Polling is MUCH easier from the client side, but more complex on the server side. It's not a web app. It's apps that integrate various devices on a factory floor. But in the past I have used polling on IE sick and the page flickered a lot when the DOM was updated. Not sure what the device browser will do.

To me a websocket is the most elegant...

Xamarin
If that's where your skills are, then maybe, but having experienced both sides, building native Android Java apps is still the least problematic route; Xamarin quite often can be more pain than pleasure.

Websockets
Read this: https://samsaffron.com/archive/2015/12/29/websockets-caution-required
ATM I tend to prefer simple tech that scales easily, websockets isn't simple and it's a challenge to scale..

Design
As to the server design, a simple JSON type web API should suffice & to avoid the need to poll is quite simply achieved by using a downstream messaging service: when changes occur on the server, the messaging service is instructed to notify all the registered clients that the data has mutated i.e. they should reconnect to the JSON API for a refresh. Messaging registration can also vary based on the dataset being accessed, or any other number of factors you require.

Btw the services can either be hosted via the cloud or internally or a bit of both. Clients can be registered to receive an unlimited number of messaging notifications.

Here's an example of one by Google: https://developers.google.com/cloud-messaging/gcm and an open source one: https://nats.io

Polling Note: the problems you've experienced with polling on IE, etc... are never an unsurmountable issue with an App; even with a constant polling the response can be completely fluid e.g. You poll a simple single value JSON API to check for data last changed timestamp, if the timestamp is different to your recorded one, you connect to the JSON data API and receive the updates. All of this happens on a background thread so no performance penalty on the mainthread, the one that is driving the UI.
Some might challenge re web builds this by saying web workers now allows Javascript to also overcome its single threading performance problems; but this is still a relatively new technology, so you'll still going to find its support across browsers is still a bit iffy + good luck finding a web developer that can actually make this work well.

Downstream messaging service
The choice of whether you use a downstream messaging service or not is really dependant on your needs and your future plans. Building a background polling solution is quick and easy, however if you're planning many such services, then the time spent to set up the messaging service would probably be justified. Either solution works well; and you could start with background thread polling and fairly easily migrate to downstream messaging at a later date or as part of another phase of implementation. The app could easily support both or others (simple app or server config)

Data standards
Naturally you could also use data standards other than JSON, however I think that should take cognisance of not only your existing standards, but also the volume of data, network latency, etc... There are a number of newer standards which have a far smaller overhead, e.g. MessagePack

Here's a recent study done by Uber on this: https://eng.uber.com/trip-data-squeeze/

Final note: Think for a moment why even companies like Google, Twitter, Uber, etc. have developed apps for many / most of their services; surely if web didn't have issues / limitations we'd never download an App.

 

[Hamster]

I don't understand the aversion to polling. Can be done with Ajax which is much easier than sockets which would probably require apps.

As long as you're not using IE or going through a proxy, websockets should be fine.

Polling is low tech and easy, sure, but websockets aren't brain surgery either.

 

[Hamster]

I really don't understand the aversion to installing apps?

For what he is doing hosting a web application is fine. Why go through the complexity of having g two separate code bases with possible maintenance and compatibility issues with future releases? Start tablet -> open browser -> local host/awesome sauce -> done.

Your biggest worry will be clearing browser cache.

 

[[)roi(]]

For what he is doing hosting a web application is fine. Why go through the complexity of having g two separate code bases with possible maintenance and compatibility issues with future releases? Start tablet -> open browser -> local host/awesome sauce -> done.

Your biggest worry will be clearing browser cache.

If the solution is that simple, I'd recommnd he question the need for ruggedized tablets; these don't come cheap + scope is rarely frozen in perpetuity at a simple display only requirement.

Ps. Even with a web solution you are still speaking about 2 codebases; server and client. Also can't see why you consider App on device to carry a higher cost: auto update handles the updates; OS updates & device maintenance would apply even if you went with a browser only solution.

 

[Hamster]

If the solution is that simple, I'd recommnd he question the need for ruggedized tablets; these don't come cheap + scope is rarely frozen in perpetuity at a simple display only requirement.

Ps. Even with a web solution you are still speaking about 2 codebases; server and client. Also can't see why you consider App on device to carry a higher cost: auto update handles the updates; OS updates & device maintenance would apply even if you went with a browser only solution.

He said they need those tablets because of a clean environment. Maybe they need to hide them down before taken in.

Having a web application that you update on one server vs. many tablets that you need to keep updated and the admin/coordination that goes with it.

Auto update might require a store so now you sit with the scenario where you need to connect to the internet first, make sure it is updated before switching back to the local network (maybe that network is isolated for a reason). You also have NO GUARANTEE that auto update will happen on every device.

If the need for an app arises you can always bring that in as a second phase. Why bring in that complexity (possibly unneeded) if you don't need to?

 

[[)roi(]]

He said they need those tablets because of a clean environment. Maybe they need to hide them down before taken in.

Having a web application that you update on one server vs. many tablets that you need to keep updated and the admin/coordination that goes with it.

Auto update might require a store so now you sit with the scenario where you need to connect to the internet first, make sure it is updated before switching back to the local network (maybe that network is isolated for a reason). You also have NO GUARANTEE that auto update will happen on every device.

If the need for an app arises you can always bring that in as a second phase. Why bring in that complexity (possibly unneeded) if you don't need to?

You're probably forgetting about corporate apps i.e. The ones that work without an internet store; even Apple caters for this.

With investment a roadmap is part of the process of justifying the expense or as part of calculating ROI. With that in mind, it's usually prudent to consider whether your medium term goals could be met with a partocular tech; because if it presents a challenge then it probably advised to address that correctly and not waste resources on something that would have to be redeveloped in a subsequent phase.

Ps. I find it strange when apps are referred to as the complex option; when most web apps pushed too far are exactly that.

The solution as described sounds far too simple to provide an adequate ROI against the cost of such devices. I had a project a few years back that involved installing ruggedized IP66 kit for POS transactioning; in the end the kit ended up being a useless investment, simply because the practicality of the day to day use had not been sufficient examined / tested, however my protestation was overridden the marketing teams: an expensive and costly mistake not only in development but also hardware, ...

In this particular example: it's probably prudent ask why not simply use the user's own device(s) i.e. if they all had Android phones, or iPhone or "heaven's forbid" Windows phones. Cost of equipping users with capable mobile phones vs cost of dedicated ruggedized devices?

 

[Hamster]

You're probably forgetting about corporate apps i.e. The ones that work without an internet store; even Apple caters for this.

With investment a roadmap is part of the process of justifying the expense or as part of calculating ROI. With that in mind, it's usually prudent to consider whether your medium term goals could be met with a partocular tech; because if it presents a challenge then it probably advised to address that correctly and not waste resources on something that would have to be redeveloped in a subsequent phase.

Actually, that happens all the time.

Ps. I find it strange when apps are referred to as the complex option; when most web apps pushed too far are exactly that.

Ok, lemme try again:

Web app access through browser: single machine deployment, single code base

Web app + Android app: server deployment + multiple device deployment, potential backward compatibility issues, multiple code bases. Boss wants to access it through his iPhone - more code that needs to be developed.

We have a term in the industry: "over engineering"

 

[FarligOpptreden]

PM sent

 

[[)roi(]]

Actually, that happens all the time.



Ok, lemme try again:

Web app access through browser: single machine deployment, single code base

Web app + Android app: server deployment + multiple device deployment, potential backward compatibility issues, multiple code bases. Boss wants to access it through his iPhone - more code that needs to be developed.

We have a term in the industry: "over engineering"

Clearly you don't understand the term over engineering, and you're sunk by the same fallacy of Flash applets, Java Applets, ActiveX, Silverlight & Web apps: the belief that its possible that a single build could deliver the best UX across all devices; if that was the case then why do apps even exist, or is your phone, tablet and PC filled with only web apps.

Oh and you probably counter by saying but code is written to make it work great on Android, great on iPhone, etc... and I'll again say that no different to multiple codebases, and then ask why apps even exist, and why most coys build apps. Oh I guess that's because they're apparently confused and haven't probably realized they're over engineering stuff that could have been done in a browser.

Ps... do yourself a favour and remember each variety of browser per OS is a deployment i.e. another instance that must be specifically coded / tested for. The example of the boss wanting it on his iPhone is a stupid one: as it implies you'd rather give everyone bad UX than customise the UX per instance. Let me guess you guys love Microsoft Sharepoint, Lotus Notes and the like...

 

[FarligOpptreden]

Clearly you don't understand the term over engineering, and you're sunk by the same fallacy of Flash applets, Java Applets, ActiveX, Silverlight & Web apps: the belief that its possible that a single build could deliver the best UX across all devices; if that was the case then why do apps even exist, or is your phone, tablet and PC filled with only web apps.

Oh and you probably counter by saying but code is written to make it work great on Android, great on iPhone, etc... and I'll again say that no different to multiple codebases, and then ask why apps even exist, and why most coys build apps. Oh I guess that's because they're apparently confused and haven't probably realized they're over engineering stuff that could have been done in a browser.

Dude, I understand all your arguments, but web applications have a place in the market. Web applications typically offer the fastest go-to-market with the widest audience with the least amount of code written. If you need to cater for almost all environments, including Windows, Mac, Linux, Android, iOS, Windows Phone, hell let's even throw in BlackBerry while we're at it, the investment needed to build a responsive web application is considerably less than building native applications for each of those devices. In a corporate environment with thousands of employees that need to access a critical application on a regular basis using any device at their disposal, you'll gain much more mileage from a web application, especially when you need to deploy updates to the server and clients.

By the sound of it, the OP has already done a bit of due diligence and realised that deploying one application to a central server and having all devices automagically receive the latest "application" when they next access it outweighs the benefit of having a native application experience on the device. This project sounds very much like a dashboard of sorts, so a responsive web application will be the best solution for this particular project, with the lowest cost and least amount of maintenance and deployment support necessary.

Why all the hate for web applications? Does this stem from your hate for JavaScript? I know you're an absolute Swift fanatic and will Swift all problems in the world away if you could, but stop being so narrow-minded and start thinking like a proper software engineer and see the benefit in all tech stacks out there.

 

[Thor]

Clearly you don't understand the term over engineering, and you're sunk by the same fallacy of Flash applets, Java Applets, ActiveX, Silverlight & Web apps: the belief that its possible that a single build could deliver the best UX across all devices; if that was the case then why do apps even exist, or is your phone, tablet and PC filled with only web apps.

Oh and you probably counter by saying but code is written to make it work great on Android, great on iPhone, etc... and I'll again say that no different to multiple codebases, and then ask why apps even exist, and why most coys build apps. Oh I guess that's because they're apparently confused and haven't probably realized they're over engineering stuff that could have been done in a browser.

Ps... do yourself a favour and remember each variety of browser per OS is a deployment i.e. another instance that must be specifically coded / tested for. The example of the boss wanting it on his iPhone is a stupid one: as it implies you'd rather give everyone bad UX than customise the UX per instance. Let me guess you guys love Microsoft Sharepoint, Lotus Notes and the like...

Apps exist as its an intermediate language that needs to be there. It won't be the case 10 years from now.

When html and css grows up hybrid apps will be the future.

Native apps is like I said a necessary intermediate technology.

 

[[)roi(]]

Dude, I understand all your arguments, but web applications have a place in the market. Web applications typically offer the fastest go-to-market with the widest audience with the least amount of code written. If you need to cater for almost all environments, including Windows, Mac, Linux, Android, iOS, Windows Phone, hell let's even throw in BlackBerry while we're at it, the investment needed to build a responsive web application is considerably less than building native applications for each of those devices. In a corporate environment with thousands of employees that need to access a critical application on a regular basis using any device at their disposal, you'll gain much more mileage from a web application, especially when you need to deploy updates to the server and clients.

By the sound of it, the OP has already done a bit of due diligence and realised that deploying one application to a central server and having all devices automagically receive the latest "application" when they next access it outweighs the benefit of having a native application experience on the device. This project sounds very much like a dashboard of sorts, so a responsive web application will be the best solution for this particular project, with the lowest cost and least amount of maintenance and deployment support necessary.

Why all the hate for web applications? Does this stem from your hate for JavaScript? I know you're an absolute Swift fanatic and will Swift all problems in the world away if you could, but stop being so narrow-minded and start thinking like a proper software engineer and see the benefit in all tech stacks out there.

The counter argument is that the lazy & bad UX option is the one that is always being adopted in your circle, but if you follow global trends building corporate apps is far more of a norm than web apps, because people have realised that a single hammer is not perfect for every nail, and to deliver the best, most flexible and not limited UX, you have to build apps.

I don't however always go for apps even if a simple web page will do; that would just be silly, but you guys covered that well enough, for my part I'm presenting the alternative; which you as a web developer may not agree with, but hey unlike you I am not as you imply limited to one programming dimension; I in fact program in more than 20 languages (and my contracts extend across the breadth of this) + I have built more than my equal share of web apps, including but not limited to Microsoft Sharepoint, Lotus Domino, Flash, Activex, Java Applets and AJAX / SOAP, ...; so it is with this experience that I comment in these threads.

Let's be honest, there is by far more web language focused developers on this forum than there are multi skilled ones; the same could be said for app developers vs. web developers.
I am certainly not placing everyone in this mold, however if you review the posts you should hopefully agree, the discussions around web development receive by in large more active participation than those not covering it. i.e. I'm not wrong to say the posts are abnormally skewed to web development, hence what is the problem with me presenting the alternative to web development and challenging misconceptions about it's complexity, etc...

 

[Hamster]

Clearly you don't understand the term over engineering, and you're sunk by the same fallacy of Flash applets, Java Applets, ActiveX, Silverlight & Web apps: the belief that its possible that a single build could deliver the best UX across all devices; if that was the case then why do apps even exist, or is your phone, tablet and PC filled with only web apps.

Oh and you probably counter by saying but code is written to make it work great on Android, great on iPhone, etc... and I'll again say that no different to multiple codebases, and then ask why apps even exist, and why most coys build apps. Oh I guess that's because they're apparently confused and haven't probably realized they're over engineering stuff that could have been done in a browser.

Ps... do yourself a favour and remember each variety of browser per OS is a deployment i.e. another instance that must be specifically coded / tested for. The example of the boss wanting it on his iPhone is a stupid one: as it implies you'd rather give everyone bad UX than customise the UX per instance. Let me guess you guys love Microsoft Sharepoint, Lotus Notes and the like...

No you're starting to assume things again and your tone is become combative which in turn makes your posts sound more juvenile than you mean them to be (I mean that PS comment of yours.... silly old man).

 

[FarligOpptreden]

The counter argument is that the lazy & bad UX option is the one that is always being adopted in your circle, but if you follow global trends building corporate apps is far more of a norm than web apps, because people have realised that a single hammer is not perfect for every nail, and to deliver the best, most flexible and not limited UX, you have to build apps.

If you're building "lazy & bad UX" on a web application, then that's exactly what you are - a lazy and bad developer. I've built web applications for clients with the slickest, cleanest and friendliest UX you can imagine. It all boils down to a developer's competence with HTML, CSS and JavaScript. When you've been doing it long enough, you started building your own libraries and frameworks to fast-track your own development whilst delivering native-class UX for your users. You could just as easily build a bad native app if you don't have a firm understanding of the technology at hand.

I don't however always go for apps even if a simple web page will do; that would just be silly, but you guys covered that well enough, for my part I'm presenting the alternative; which you as a web developer may not agree with, but hey unlike you I am not as you imply limited to one programming dimension; I in fact program in more than 20 languages (and my contracts extend across the breadth of this) + I have built more than my equal share of web apps, including but not limited to Microsoft Sharepoint, Lotus Domino, Flash, Activex, Java Applets and AJAX / SOAP, ...; so it is with this experience that I comment in these threads.

...and similarly I don't always ascribe to a web application. Horses for courses and all that. I'm not going to go into a language-pissing contest, but I've also used my fair share of programming languages in a wide variety of applications to feel comfortable in making recommendations to clients.

Let's be honest, there is by far more web language focused developers on this forum than there are multi skilled ones; the same could be said for app developers vs. web developers.
I am certainly not placing everyone in this mold, however if you review the posts you should hopefully agree, the discussions around web development receive by in large more active participation than those not covering it. i.e. I'm not wrong to say the posts are abnormally skewed to web development, hence what is the problem with me presenting the alternative to web development and challenging misconceptions about it's complexity, etc...

Again, it depends on your grasp of the technologies at hand. Web applications can be deceptively simple if you use the right libraries and frameworks. Again the same argument can be made for native applications, where the complexity quickly ramps up with server API's feeding data to the thin clients, security often not being implemented properly and, once again, deployment and maintenance after go-live.

The development industry is very much an economy on its own - the reason why there's so much discussion surrounding it in the local (and international) scene, is because there's such a huge demand for it. Even when you're building a native application connected to a central server, you in essence have a "web application" (sans UI) providing consumers with data and business logic (if you're following a SOA approach). So the interest and number of discussions surrounding web applications will always outnumber those of native applications, because that's the nature of modern applications and everything wanting to be part of the IoT.