To be or not to be: A real app.


App is the new black, everyone talks about downloading, buying or selling apps, advertising about them is everywhere. The phone manufacturers have marketplaces and stores where phone users can get get those "apps".

We all know the term app is short from application. If this term was coined because was easier or because of a marketing strategy I don't know. But it is catchy, and so we will use it. But to be exact on term, int this case it means "mobile application". Otherwise any program would be an app right?

But exactly what is an "app",  really ? 

Third-party programs running on mobile is not something new at all, for  more than 10 years we had Java Midlets for almost any kind of cell phone, and I myself programmed for years for the Pocket PC and Windows Mobile, using either eVC, eVB, and later any .NET language like C# or VB.NET by using the .NET Compact Framework (.NET CF). And all those were actually apps. So, if is not new, why the boom now?

We can spot 2 main differences in today's app model, if we look back in time.

1) The deployment/installation mode.

Before the Apple App Store, Microsoft Zune Marketplace, Android's Market and similar came to exist, we used to manually put the programs in our phones, either by following a link that will do the "automatic" installation, running a setup program on the phone,  or from the desktop by using Active Sync, Windows Mobile Center or a similar tool. To be honest, it was not a good time for developers like me, because around 80% of the support questions I got were about "how to setup" the program on the device.

But we the new model to download and install apps, is even easier. And one of the best things of this model is that your app is right away available to million of users, also, as an end-user, you have access to a lot of apps on a single place, and by "a lot" I really mean that many. Just by googling around I see there are about:

  • 425,000 for iOS
  • 319,000 for Android
  • 43,000 for Windows Phone

The new model to distribute mobile applications comes with a drawback; for platforms like the iPhone/iPad and Windows Phone, you can't just run your program there, you need to put it on the store, and wait to "be accepted". So sometimes you could use a different approach like the Vatican personal did.

You might also have to pay a developer or publisher license, and give the store a cut (30% on Apple Store) and might be subject to more restrictions. But hey, now everyone can find our apps and we don't need to explain people HOW to install them.

2) Where the "real thing" happens?

The other important part was the fact, that "old apps" used to be executed entirely on the device, no matter if the program used a Internet connection to communicate with a server or a service somewhere. The programs always, did run on the device. Otherwise it was just a website fitted for the device.

That line is not "solid" anymore, the term app, no longer means you have a program on your device. Sometimes all your app does is to have a shortcut to the phone's browser that will open a website designed to match your device screen and browser capabilities. The good part is that regular users don't know that (and what is more important, they don't care about it) to use the app. The bad part of this is that you likely won't be able to use the app if you are offline. Of course some apps are a mix of both things.

There is also features like accessing devices camera(s), GPS, storage, sensors, memory storage, function keys and video acceleration that you most probably wont be able to use it from a web browser.

So, which one is a real app?

Just to be fair with technical terms, all of them are apps, from the end-user's point of view. For me, as a developer, a real app runs on the device, although it might use online services to store data on the cloud, or retrieve information (like maps or images). Otherwise, is just a shortcut to a web site that is well fit for the device, so here "web app" would be a proper term.

We also now got the new term "web app", although that would be material for another day.



Comments

Post a Comment

Popular posts from this blog

Get-ChildItem vs Dir in PowerShell

Image
Batch as usual Recently I was in the need of modifying a huge amount of files across a network share. After installing Serviio media streaming service I noticed that it will crash "randomly". After checking the logs it was clear that ffmpeg was crashing when trying to open subtitle files that were not in the encoding indicated by the Serviio console. I needed a quick way to update all subtitle files to a common encoding, so I decided to convert all files to UTF8. Since I use a windows environment I went directly to PowerShell and wrote this.  Get-ChildItem -path .\ -filter *.srt -file  | ForEach-Object { (get-content $_.FullName) | Out-File $_.FullName -encoding utf8 } This worked almost right except for files with "[" or "]" (among other symbols) on the name or path. To solve it, just added the "-LiteralPath" switch to tell powershell not to consider any wildcards on the path name and just use it exactly as it is.  Get-ChildIt...
Read more

The case for a 4 week sprint

Image
Every time we talk about SCRUM, the length of the sprint is stated as a period of "two to four weeks", rarely, however, have I seen people going outside of the 2 weeks. This is not written on stone of course, and while 3 weeks might seems odd, there is a benefit to using a longer period for your sprints.  Image is taken from scrum.org Without any hard data to back that decision, the answer I get from asking about this decision seems to be related to "delivery speed", we assume that because we deliver value to the business every 2 weeks, we are in a more "agile" environment. Well, that might not be so true in every sense or for every project. Let's break some arguments: 1. Sprint length is not equal to the speed of delivery There is more to the speed of development and delivery than the timeframe of the delivery cycle, in a world with DevOps and full CI/CD implemented for your project, you could (should?) actually deliver features every single day all t...
Read more

NODE.js fs.readFile and the BOM marker

Working on a ReactJS project, got a small glitch while trying to read a JSON file and parse it as a javascript object. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString); } output:   SyntaxError: Unexpected token   After checking, double and triple checking again that the file was correct I went deeper and realized that "fs.readFileSync" was returning me the BOM for the UTF file at the beginning of the string. So we just need to strip it out. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString.replace(/^\uFEFF/, "")); } I then checked and there are "packages" for this, however I don't think is proper to just import a new dependency just to fix something this small. The big issue here is why is this considered correct. The BOM is not ...
Read more