With mobile cloud computing come efforts to simplify its development. Creating apps for the mobile cloud is significantly different than developing apps for a native smartphone platform. This session is about design and architecture considerations, the essential tools and technologies, and the pitfalls to avoid when building mobile cloud apps.
Anywhere means any device, any application, anywhere a user wants to be able to access their content. So, that’s where I come in – I build Box’s mobile apps so that users can access their content from anywhere.
When you first start developing an application you care intensly about solving a single use case.
We like this because you can perfectly fulfill your intended use case. And you have complete control over the experience. A user opens your app and stays inside.
This is great for something like Angry Birds
But what if you want to build something for productivity like a Voice Recorder application, document reader, sketch application or a word editor? Oftentimes your application isn’t stand-alone and the use case doesn’t stop and end on the device. For your application to fulfill a broader use case and play well with the rest of a users life, you’ve got to play well in the broader ecosystem
End-to-end workflow: Really it comes down to *workflow.* Your application is just a part of a bigger story. Either it exists to augment the service it's on top of or it's on of a larger constellation of apps that a user needs to complete their desired task. Users expect changes in your application to be visible across the web, related integrated apps, the desktop. All that information in sync all the time.
One example that we see a lot at box is document workflow Users want to open a document, edit it, comment, add photos, save that doc and then access it from anywhere again. That’s really too much for a single app to do. So you have to be able to integrate with other apps on the device
What’s more, users want to make workflow happen across devices. They want to have access to the state of your application across any device and both native apps and on the web.
And it’s not just me saying it. At Box we’ve seen that our users are becoming more and more mobile and that they’re logging in from more and more locations – mobile phones, computers and the web. Having your application accessible from different locations is more important than ever. 6 different locations by detecting IP addresses on site visitors. Where users are logging in from. IP can determine different devices from different. Use it at work. Home computer, work computer, personal devices. Google Analytics.
So from your perspective, your app gets inputs and outputs of information. The app’s start-state depends on a user’s actions on other devices, computers and websites. If it’s a social app it could depend on your user’s friends actions from other services. At the same time, your application could send state out to other apps
Your application should always know the state of the user’s data, no matter where when or how they last touched your application or a partner’s application. Your content is just a window into content that exists somewhere in the ether. Also, it doesn’t matter whether you and another app developer communicate with each other, if a user for whatever reason expects that something they do in one app be reflected in another, you should make sure those changes are reflected in both of your applications Everything they need should just “be there”.
In reality, information is flowing all over the place from many different channels. Applications are pulling information from APIs from databases across the web. Applications are rendering webpage content from different sites using WebViews Website integrations are pulling information from other website’s databases.
Spotify pulls friends’ information from facebook and loads songs remotely via an API
Facebook in flipboard: login webview
Box in Quickoffice
Bookmarks in the Box app
To build the best-behaved application you can, you need to expose your application’s data in as many ways as possible . You also need to make sure you’re utilizing all the data that your customers expect. For this Tools section, I’m going to focus on Android and iOS, the main front-runner OS’s
To start, let’s talk about Device APIs
Send content between applications – documents in general, but also any information that can be contained within a URL. Custom URL handlers work from the web, from other apps or from email links. Great way to launch your application from within another app or program.
To start, let’s talk about Web APIs
Mobile devices have a hard time processing complex Requests and Responses. You don’t want to be parsing complex XML with a simple event-driven parser There are usually numerous libraries out there for APIs that other people have built applications on top of – take advantage of them!
Oauth – redirects to a different page. You only get what the service wants you to get. Most common login type If there is a ‘direct login’ make sure you’re not doing anything to save the password. All communication uses a token that can be revoked by the user on the main web app side. Make sure you’re only using that.