Building Enterprise Smartphone App – Part 4: Application Development Considerations
- by Tim Murphy
This is the final part in a series of posts based on a talk I gave recently at the Chicago Information Technology Architects Group. Feel free to leave feedback. Application Development Considerations Now we get to the actual building of your solutions. What are the skills and resources that will be needed in order to develop a smartphone application in the enterprise? Language Knowledge One of the first things you need to consider when you are deciding which platform language do you either have the most in house skill base or can you easily acquire. If you already have developers who know Java or C# you may want to use either Android or Windows Phone. You should also take into consideration the market availability of developers. If your key developer leaves how easy is it to find a knowledgeable replacement? A second consideration when it comes to programming languages is the qualities exposed by the languages of a particular platform. How well does that development language and its associated frameworks support things like security and access to the features of the smartphone hardware? This will play into your overall cost of ownership if you have to create this infrastructure on your own. Manage Limited Resources Everything is limited on a smartphone: battery, memory, processing power, network bandwidth. When developing your applications you will have to keep your footprint as small as possible in every way. This means not running unnecessary processes in the background that will drain the battery or pulling more data over the airwaves than you have to. You also want to keep your on device in as compact a format as possible. Mobile Design Patterns There are a number of design patterns that have either come to life because of smartphone development or have been adapted for this use. The main pattern in the Windows Phone environment is the MVVM (Model-View-View-Model). This is great for overall application structure and separation of concerns. The fun part is trying to keep that separation as pure as possible. Many of the other patterns may or may not have strict definitions, but some that you need to be concerned with are push notification, asynchronous communication and offline data storage. Real estate is limited on smartphones and even tablets. You are also limited in the type of controls that can be represented in the UI. This means rethinking how you modularize your application. Typing is also much harder to do so you want to reduce this as much as possible. This leads to UI patterns. While not what we would traditionally think of as design patterns the guidance each platform has for UI design is critical to the success of your application. If user find the application difficult navigate they will not use it. Development Process Because of the differences in development tools required, test devices and certification and deployment processes your teams will need to learn new way of working together. This will include the need to integrate service contracts of back-end systems with mobile applications. You will also want to make sure that you present consistency across different access points to corporate data. Your web site may have more functionality than your smartphone application, but it should have a consistent core set of functionality. This all requires greater communication between sub-teams of your developers. Testing Process Testing of smartphone apps has a lot more to do with what happens when you lose connectivity or if the user navigates away from your application. There are a lot more opportunities for the user or the device to perform disruptive acts. This should be your main testing concentration aside from the main business requirements. You will need to do things like setting the phone to airplane mode and seeing what the application does in order to weed out any gaps in your handling communication interruptions. Need For Outside Experts Since this is a development area that is new to most companies the need for experts is a lot greater. Whether these are consultants, vendor representatives or just development community forums you will need to establish expert contacts. Nothing is more dangerous for your project timelines than a lack of knowledge. Make sure you know who to call to avoid lengthy delays in your project because of knowledge gaps. Security Security has to be a major concern for enterprise applications. You aren't dealing with just someone's game standings. You are dealing with a companies intellectual property and competitive advantage. As such you need to start by limiting access to the application itself. Once the user is in the app you need to ensure that the data is secure at all times. This includes both local storage and across the wire. This means if a platform doesn’t natively support encryption for these functions you will need to find alternatives to secure your data. You also need to keep secret (encryption) keys obfuscated or locked away outside of the application. People can disassemble the code otherwise and break your encryption. Offline Capabilities As we discussed earlier one your biggest concerns is not having connectivity. Because of this a good portion of your code may be dedicated to handling loss of connection and reconnection situations. What do you do if you lose the network? Back up all your transactions and store of any supporting data so that operations can continue off line. In order to support this you will need to determine the available flat file or local data base capabilities of the platform. Any failed transactions will need to support a retry mechanism whether it is automatic or user initiated. This also includes your services since they will need to be able to roll back partially completed transactions. What ever you do, don’t ignore this area when you are designing your system. Deployment Each platform has different deployment capabilities. Some are more suited to enterprise situations than others. Apple's approach is probably the most mature at the moment. Prior to the current generation of smartphone platforms it would have been Windows CE. Windows Phone 7 has the limitation that the app has to be distributed through the same network as public facing applications. You mark them as private which means that they are only accessible by a direct URL. Unfortunately this does not make them undiscoverable (although it is very difficult). This will change with Windows Phone 8 where companies will be able to certify their own applications and distribute them. Given this Windows Phone applications need to be more diligent with application access in order to keep them restricted to the company's employees. My understanding of the Android deployment schemes is that it is much less standardized then either iOS or Windows Phone. Someone would have to confirm or deny that for me though since I have not yet put the time into researching this platform further. Given my limited exposure to the iOS and Android platforms I have not been able to confirm this, but there are varying degrees of user involvement to install and keep applications updated. At one extreme the user just goes to a website to do the install and in other case they may need to download files and perform steps to install them. Future Bluetooth Today we use Bluetooth for keyboards, mice and headsets. In the future it could be used to interrogate car computers or manufacturing systems or possibly retail machines by service techs. This would open smartphones to greater use as a almost a Star Trek Tricorder. You would get you all your data as well as being able to use it as a universal remote for just about any device or machine. Better corporation controlled deployment At least in the Windows Phone world the upcoming release of Windows Phone 8 will include a private certification and deployment option that is currently not available with Windows Phone 7 (Mango). We currently have to run the apps through the Marketplace certification process and use a targeted distribution method. Platform independent approaches HTML5 and JavaScript with Web Service has become a popular topic lately for not only creating flexible web site, but also creating cross platform mobile applications. I’m not yet convinced that this lowest common denominator approach is viable in most cases, but it does have it’s place and seems to be growing. Be sure to keep an eye on it. Summary From my perspective enterprise smartphone applications can offer a great competitive advantage to many companies. They are not cheap to build and should be approached cautiously. Understand the factors I have outlined in this series, do you due diligence and see if there is a portion of your business that can benefit from the mobile experience. del.icio.us Tags: Architecture,Smartphones,Windows Phone,iOS,Android
