The Client Side
Yup, desktop apps are not left out of the mix. Most desktop solutions fall into a category similar to Apache Cordova, where the end results is a web view that has access to lower level APIs, whose content is developed with web based technology.
Electron – Node.js + Chromium desktop app container from GitHub
app.js – Node + Chromium for a desktop app container
nw.js – Another framework for Node +Chromium for a desktop app container
CEF – The Chromium Embedded Framework – a framework for embedding the guts of the chrome browser inside of a desktop app.
… and more… I know Microsoft has a solution for building Windows apps purely out of HTML/JS, and there are more solutions out there that I am forgetting.
Here are some stats that show the magnitude of growth and adoption for Node.js/npm.js alone. NPM stats currently shows a total of 186,946 packages available for download, 94,978,032 package downloads in the last day, and 2,451,734,737 package downloads in the last month.
Node.js adoption is massive, and is still growing.
That title get your attention? Yes, it really read “Adaptive mobile apps that change based on personal context” – with near real-time rules application, without much extra development effort. If that sounds interesting to you, or like a product you might want to use within your own apps, then you might want to check out this site where you can get involved in the product’s development: http://adaptiveexperience.mybluemix.net/
IBM is looking for your input on creating these types of mobile app experiences. User experiences within a single app that can be dramatically different per user based on location, past behavior, profile information, social media activity, and so much more. With this behavior being driven by configurable rules that can be changed without redeploying an app to the app store.
How it works for your customer
Consider this scenario:
Jon and Andrea download the mobile app for S&W, a retailer known for its attention to providing great customer service. Over the next month, Jon and Andrea use the app to browse and discover content and merchandise differently.
Jon primarily navigates to sports related content for his favorite teams to find gear and clothes for travel to his favorite team’s games. Andrea scours the app for sales and fashion trends and usually ends up following her favorite designers.
Andrea and Jon go to a baseball game together. She’s never enjoyed watching it, so she opens up the S&W app to entertain herself, and her app’s navigation quickly steers her through Spring fashion articles.
Jon however, wants to replace the hat he’s worn the last three times the team lost, and since he’s in the stadium, his S&W app opens right up to the team’s gear page. The app knows he’s out of town and tells him how to get to an S&W store.
How it works for the dev team
Consider another scenario:
One of the developers on the team, George, sets up the system and application. He then gives access to Janet who is responsible for the customer experience.
Janet writes rules defining how the application could adapt and become more personalized based on inputs like , social media, geolocation, app usage, or customer information data.
Once Janet has built out her rules, she simply hits ‘Submit’ and can immediately see her clever interactions reflected in the mobile application without having to involve the development team.
Analytics let Janet know which adaptations are working best, and helps her find new opportunities to optimize the app’s user experience.
We’re not talking about a content management system, or translation based on locale, instead a rules-driven product that can adapt literally every aspect of your app: customize the user interface, enable or disable different features, customized messaging and notifications, and much more, all variable based upon the user context. This can be used to present contextually relevant information, drive adoption, provide more/less data depending on your physical context, and so much more.
It won’t be tied to a specific UI framework, won’t be tied to a specific content management system, isn’t attempting to re-create Google Now or Apple Proactive Assistance. Rather, a set of tools and a rules engine that enable you to customize and tailor the app experience to the individual user.
Earlier this week I had the privilege of speaking at ApacheCon in Austin, TX on the topic of data management for apps that work as well offline as they do online. This is an important topic for mobile apps, since, as we all painfully know already, there is never a case when you are always online on your mobile devices. There always ends up being a time when you need your device/app, but you can’t get online to get the information you need. Well, this doesn’t always have to be the case. There are strategies you can employ to build apps that work just as well offline as they do online, and the strategy I’d like to highlight today is based upon data management using the IBM Cloudant NoSQL database as a service, which is based upon Apache CouchDB.
Here’s a link to the presentation slides (built using reveal.js) – just use the space bar to advance the presentation slides:
The “couch” in CouchDB is actually an acronym for Cluster of Unreliable Commodity Hardware. At the core of this cluster is the concept of replication, which in the most basic of terms means that data is shared between multiple sources. Replication is used to share information between nodes of the cluster, which provides for cluster reliability and fault tolerance.
If you’d like to learn more about replication in Cloudant and CouchDB, you can read more using the links below:
Cloudant is a clustered NoSQL database services that provides an extremely powerful and searchable data store. It is designed to power the web and mobile apps, and all information is exposed via REST services. Since the IBM Cloudant service is based on CouchDB (and not so coincidentally, IBM is a major contributor to the CouchDB project), replication is also core the the Cloudant service.
With replication, you only have to write your data/changes to a single node in the cluster, and replication takes care of propagating these changes across the cluster.
If you are building a native app, don’t worry, you can take advantage of the Cloudant Sync API to leverage the local data store with replication. This is available for iOS and Android, and implements the CouchDB replication API.
The sample app that I showed in the presentation is a native iOS application based on the GeoPix MobileFirst sample app that I detailed in a previous post. The difference is that in this case I showed it using the Cloudant Sync API, instead of the MobileFirst data wrapper classes, even though it was pointing at the exact same Cloudant database instance. You can see a video of the app in action below.
All that you have to do is create a local data store instance, and then use replication to synchronize data between the local store and a remote store.
Replication be either one-way (push or pull), or two-way. So, any changes between the local and remote stores are replicated across the cluster. Essentially, the local data store just becomes a node in the cluster. This provides complete access to the local data, even if there is no network available. Just save your data to the local store, and replication takes care of the rest.
In the native Objective-C code, you just need to setup the CDTDatastore manager, and initialize your datastore instance.
Once your datastore is created, you can read/write/modify any data in the local store. In this case I am creating a generic data object (basically like a JSON object), and creating a document containing this data. A document is a record within the data store.
You can add attachments to the document or modify the document as your app needs. In the code below, I add a JPG atttachment to the document.
[logger logDebugWithMessages:@"Document created ID: %@", doc.docId];[/objc]
Replication is a fire-and-forget process. You simply need to initialize the replication process, and any changes to the local data store will be replicated to the remote store automatically when the device is online.
[objc]//initialize the replicator factory with the local data store manager
CDTReplicatorFactory *replicatorFactory =
[[CDTReplicatorFactory alloc] initWithDatastoreManager:self.manager];
By assigning a replicator delegate class (as shown above), your app can monitor and respond to changes in replication state. For example, you can update status if replication is in progress, complete, or if an error condition was encountered.
If you want to access data from the local store, it is always available within the app, regardless of whether or not the device has an active internet connection. For example, this method will return all documents within the local data store.
Last month I had the opportunity to speak at the DevNexus developer conference in Atlanta on building native iOS apps IBM MobileFirst. DevNexus is a great event, and it is always a privilege to attend – I highly recommend it for next year. If you weren’t able to make it, no worries! Most of the sessions were recorded and are available for viewing online via dzone.
The recording of my session is embedded below. It covers everything you need to know to get started building apps with the MobielFirst platform.
Once your app goes live in the app store you will have just entered into an iterative cycle of updates, improvements, and releases. Each successively building on features (and defects) from previous versions. IBM MobileFirst Foundation gives you the tools you need to manage every aspect of this cycle, so you can deliver the best possible product to your end user. In this session, we’ll cover the process of integrating a native iOS application with IBM MobileFirst Foundation to leverage all of the capabilities the platform has to offer.