In a recent blog post, I walked through setting up a SharePoint 2013 development environment in the cloud. After doing that, the next most logical step was to start building apps. But that meant that I would have to understand what a SharePoint app really was and how it differed from SharePoint 2010 development. I mean sure, I could bang out the typical “Hello World” app, but to do anything meaningful, I needed to dig a little deeper.

Apps vs. Solutions

An app for SharePoint is a stand-alone, self-contained piece of functionality that extends the features and capabilities of a SharePoint site. Apps can bring together the best of both worlds; modern web technologies and all the familiar pieces of SharePoint. On top of that, users can discover and download apps on their own from the public Office Store or from their organization’s private App Catalog. In contrast, a solution is used to customize or enhance SharePoint sites and needs a farm administrator to deploy, manage and remove.

Why Apps?

The first question that I asked myself was why would you use an app? I would assume that the answer to this question might depend on who you polled, but as a developer, I am extremely excited that I can now leverage all of the exciting things that my “non-SharePoint” counterparts have been doing for quite some time. In my opinion, this paradigm shift is a smart move by Microsoft, and will go a long way in attracting more developers to the platform.

Read More…

Windows 8 Desktop

Microsoft has been a busy company this year with refreshes on most of its biggest solutions. Not only has SharePoint gone through a massive update, but so has Windows. If you’re still unfamiliar with the changes in Windows 8, then be prepared for a shocker. In the new UI, applications have been stripped of chrome and are full-screen solutions. Windows 8 was designed with touch as a first-class input method.

SharePoint 2013 brings several new features, but the two that will empower client application development the most are the greatly expanded Client-Side Object Model (CSOM) and the REST APIs. While the maturity of these features is important for Microsoft’s push to SharePoint Online and client-side development, it also opens up complex functionality for Windows, mobile, and external web applications. Read More…

One of the tasks we are beginning to explore at AIS is developing and distributing mobile applications for our corporate clients. One common scenario will be for these apps to be available only for their employees, or a select group of their clients. So distribution through Apple’s App Store, for example, may not be an acceptable solution.

There are several options for distributing enterprise iOS applications, if we can’t (or don’t want to) go through the App Store:

1. Ad Hoc distribution. This involves building the distribution files, distributing them to the clients (via email or posting them to a server), and having them drag the files to iTunes and then synchronizing their devices. That’s a little messy. And it requires repeating the process every time there is an update to the app.

Again, this is a messy process, and will have to be repeated for each update and new app.

2. iPhone Configuration Utility. Apple’s iPhone Configuration Utility (Mac version; Windows version; documentation) is another option. This leaves the task to the system administrator, and is labor intensive. The SysAdmin will either need to attach to each device, and install the provisioning profiles and the apps, or email the configuration profile to each user. A generic profile can be used across the organization, but if username and password management are a part of the profiles, then it gets very complicated, very quickly. Again, this is a messy process, and will have to be repeated for each update and new app.

3. Mobile Device Management. The SysAdmin can install apps through MDM (Mobile Device Management, requires sign-in). Again, device management is required, but MDM allows for remote management once the device has been initially configured. When a new or updated app is available, the administrator creates a new payload, sends a push notification (through Apple’s Push Notification Service) to the appropriate client devices, and the devices execute the command (in this case pulling down and installing the app in the payload). If MDM is already a feature in the organization’s administration processes, this is a viable option.

4. Distribute apps wirelessly, using the Over the Air (OTA) process. This is the route I’ll discuss in detail, as it seems to be the most straightforward and easiest to implement of the available options, especially if MDM is not applicable. There are some wrinkles, too, which can automate the process of updating/upgrading the apps transparent to the users.

Read More…