Category: Mobile

Running apps without connectivity

cvjepsen6 Comments

The other day on my daily commute I was, as usual, reading the latest news on technology and other, to me, interesting areas, I ended up spending most of my commute reflecting on the subject of mobile apps supporting disconnected state instead of reading. Honestly, I was rather annoyed with the situation, as I really enjoy being able to read my news and emails while riding the train.

So what was difference this particularly morning, since I usually read news and emails while on the train? Well, the difference was that normally I’m on an InterCity train that offers free WIFI, however, on this day I got on an earlier train – the sprinter – which doesn’t have free WIFI. Meaning, that I had to rely on “standard” mobile connectivity, which can be sketchy, even in a country like the Netherlands that got exceptional good network coverage.

Being without reliable connectivity I started testing a number of different news reader apps like Zite, FlipBoard, Dr. Dobbs and others – and found that they all requires connectivity to function. None of the newsreaders I tried, offered any solution for reading news without having connectivity. Which is some part peculiar, and I would argue a major flaw. Most of the apps build personalized news based on users preferences, it’s not as they’re searching the net for news. They could easily, on launch, download the news the user are interested in and store it on the device, and whenever there’s connection sync with the server.

If you think about this, then most of these apps and any other app that relies on connectivity is simply a revamped web app, and they doesn’t really offer any noticeable better user experience than a mobile web app would do. So why even bother building these apps as native apps? Apart from be able to distribute them as native apps by means of the app stores. But honestly, these apps don’t provide any additional advantages over traditional web apps.

When building native apps for devices like the iPad it’s crucial that there are additional benefits for the user over building mobile web apps. And one of these additional benefits is the ability to design and create apps that are capable of running without connectivity – disconnected. Remember that the mobile devices got – nearly – all the capabilities of a modern laptop. Storage, file system and database, so there’s a lot of power of API available to facilitate a great user experience, even when the device is disconnected.

When building mobile apps, you should rethink the functionality in terms of being disconnected. Look at the use case you’re trying to solve, and then rethink the use case in the light of being disconnected. Ask yourself, what your users wants to be do if there’s no connection. In the example of reading news, then I would assume that my users would like to be capable of reading news regardless of whether or not there’s connectivity. Compare it with reading a newspaper, and provide similar functionality – since that’s what the newsreader is trying to substitute – the good old newspaper. For the current mainstream apps in the newsreader space, they clearly haven’t succeeded in providing that richer user experience.

And to everyone out there, arguing that there’s such thing as perpetual connectivity, I suggest you go on a road trip, using different means of transportation as that’ll make you understand that perpetual connectivity doesn’t exists.

Smart Clients Versus Web Clients – What’s the Answer?

cvjepsenLeave a comment

For a long period of time every ISV jumped on the browser bandwagon, meaning creating web versions of their existing fat clients. This transition was driven by Google’s everything web mantra, together with the emerging cloud technologies. The transition was moreover an answer to requirements from CIOs all over the world for an easier deployment when upgrading software internally. With a browser based app, you only need to update the server – and all of your users would automatically get upgraded. This approach would allow companies to purchase inexpensive computer equipment as the hardware literally only need to be capable of running a browser. Which is the whole idea being Google’s ChromeOS.

Initially moving away from fat clients to browser based app was painful. Mostly due to the limited capabilities of the web browsers, causing limitations to how advanced one could make the browser based apps. Over time the browser and standards behind the web (HTML, CSS and JS) became more and more sophisticated, allowing developers to create more rich web applications – Rich Internet Applications. With RIA developers could offer near desktop like experiences to their users, everything still within the framework of the browser. The browser became a platform for application execution, instead of a render of web information – which was the original purpose.

Alongside the continuously enhancement of web technologies to provide richer user experiences, or experiences close to what could be offered with native developed and deployed applications, technologies like MS NoTouch and Java WebStart emerged. These technologies solved the deployment headaches organizations had with traditional fat clients, by automatically downloading the app to your computer and execute it. If there was an update, you simply updated the server version – and the clients would automatically download the updated version. No need for IT personnel to physical be present to install software on individual computers. This was essentially the birth of the smart client. A desktop client that gave you all the benefits, like tight integration with the underlying OS and other components on the computer, offering features like drag’n drop.

An advantage of web clients is that you can access your data from any device, as the data or documents doesn’t reside locally. However, on the flip side that means that you can’t access your data UNLESS your connected to the internet. Smart clients allow you to store data locally, BUT then you can’t access your data unless you’re on the same device. With HTML5 and recent new specifications this is somewhat resolved. In HTML5 there’s the notion of local storage, the ability to store data locally in your browsers cache. Either as sessions data or actually local data. The latter allows you to store data locally and have that data available even if you’re disconnected. Drawback is that if users clears their cache all local data is gone. There’s another specification (http://dev.w3.org/html5/webdatabase/) defining an API for accessing a local SQL database.

Overall the HTML5 specification itself and the adjunct specification all serves the same purpose, trying to narrow the gap between web apps and clients executed on the device. Both in terms of User Experience and capabilities in terms of storing data locally. One of the key features of a traditional as well as smart client.

At WWDC 2011 Apple showed the way for allowing Smart Clients to seamlessly store any data in the cloud, so that you’ll be able to get to your data regardless of what device you’re using. They took NoTouch and WebStart further. With Apple’s new technologies you can develop applications that’s downloadable from the Mac or iOS AppStores, and they’ll get updated automatically when new versions are made available – same as NoTouch and WebStart. These applications can use the iCloud for storing data in the cloud so that the same data will be available on other devices, allowing you to seamlessly move between different devices, like a Mac, iPad, iPhone or iPod. The users don’t need to think about where their data is, “it just works” as Steve Jobs put it.

Will others adopt this approach? Personally, I wouldn’t be surprised if Microsoft does. That’ll allow them to keep their products as is, and at the same time get users to use Azure. They could of course go all web, as they partly have done with offering Office as a web offering, but honestly, Microsoft isn’t a web company. Just like Apple aren’t a web company. Only web company in this game is Google.

So looking at the recent development among web technologies, and recent announcements from Apple you’re moving to a point where the gap between web clients and smart clients are narrowing. This being said, then the smart clients with the close integration with the underlying OS still offers superior User Experience than a browser hosted application.

So what will the application of the future be? Browser based application or a Smart Client. Where the latter uses all the services available on the internet, and at the same time offers native capabilities. Personally I believe that we’ll see more native applications in the Apple world, as there’s a lot of developers that previous worked on iOS using Apple’s tools – that now can start thinking about building integrated applications across multiple devices, without the maintenance nightmare of having to update computers by manually installing the updated. If Microsoft follows suit and start adopting the Apple approach in Windows 8 and later on tablets – my take is that the road it paved towards more Smart Clients and less browser based clients.

Native Tooling versus Non-native Tooling

cvjepsenLeave a comment

Recently I’ve been following some interesting discussions on the subject whether to develop native apps for mobile or using cross platform technologies. Let me elaborate what I mean by native apps. A native app is an app that is built using the tooling provided by the vendor. So for iOS devices that would be Objective-C and cocoa touch, for Android and RIM that would be Java.

Mostly the discussions seems to be concentrating on two underlying subjects: 1) how to utilize existing skills and framework knowledge and 2) how to support multiple mobile platforms with one code base. You can argue that these two subjects are intertwined and cross platform solutions tries to solve both areas simultaneously. Which is somewhat correct; however, #2 actually got another level as well, as there’s a whole range of MEAP vendors trying to push “code free” solutions, requiring none or limited coding.

Let’s look at #1 and what seems to be the key driver behind wanting to use existing tooling or similar tooling and technologies. Well, should be obvious, mostly seems to stem from a wish either to save money or reuse skills. The former is primarily driven by organizations whereas the latter is developers wanting to develop apps, but don’t want to go through the hassle of learning and new set of tools and technologies (see my blog on this, choosing the right tools). Also, there’s the latest SDK problem. If you’re using native you’ll always have the latest and greatest SDKs at your disposal; whereas if your going with non-native you’ll have to wait until the vendor gets his version ready. The time the vendor uses to do that, your competitors that uses native SDKs exploit new features and leaves you behind.

#2 is a repeat of previous attempts to find a silver bullet for supporting a number of platforms, build-once-deploy-many. So far nobody have succeeded in this field, at least not that I’m aware of. Back in the early nineties a substantial number of companies tried to build CASE tooling in an attempt to abstract the development away from code and hence be able to design once deploy many. Nobody uses CASE tools today. There was also a number of attempt trying to build cross platforms for Wintel and Macintosh. None of these are around. Personally I wouldn’t hold my breath or bet my business on the MEAP vendors, they’ll be gone as soon as the mobile OS market starts congregating towards 2 maybe 3 platforms.

Another thing about MEAP is that in trying to target many platforms they end up having to go with the least common denominator. And frameworks typically gives you 80% of what you need, the last 20% you can’t do and have to go into native code anyway. And guess what, it’s the last 20% of finalizing the project that takes 80% of the time. So no real gain (only a lot of pain).

Another important and often forgotten subject is the user base of certain technologies. The more users using specific technologies the easier it is to get help, find solutions and sample code. With lesser user adoption you’ll be more left on your own and can only rely on the vendor, who will most likely charge you for anything and everything possible.

If you haven’t already guessed then my stand is native everything, you get better apps, they look cooler, they feel like native apps, you don’t risk having to wait for a vendor to implement latest and greatest features, you don’t risk a vendor suddenly going out of business, you got huge user communities that can help and you won’t end up being charged unreasonable amounts of money for simple questions.