The Five Elements Of Software Engineering For Mobile (Part 2)

Software Engineering for MobileThis is the second part of our series about the five elements of software engineering for mobile. Part one was about the main differences and challenges of software engineering for mobile vs “conventional” software engineering.

This blog post series is based on a keynote talk to computing students at the Imperial College, London, during the kick-off event for their summer group projects, aimed at the development of an innovative web or mobile-based app. The talk should help the students getting a more holistic view about software engineering for mobile and highlight the following five key elements:

  1. Make the right technical platform choice for your context (this part)
  2. Get the UX right (Part 3)
  3. Choose the right methodologies in the areas of building a business, customer development and product development (Part 4)
  4. Enrich the functionality of your app by integrating Internet-based APIs (Part 5)
  5. Leverage the power of tools (rather than reinventing the wheel) (Part 6)

In this second part I cover the first element “Make the right technical platform choice for your context” in more detail. We will publish another part every week, so make sure to check back soon.

 

Key element 1:

Make the right technical platform choices for your context

The first key element in software engineering for mobile is to make the right choice of technical platform, and the technology for implementing the software, which can differ substantially. The drivers for these choices may be very different and depend on a developer’s specific context. It may simply be related to preferences but the decision should be clearly informed by the objective and which platform and surrounding ecosystem can support that best.

Related to the platform decision is also whether an app should be implemented natively with focus on the target platform(s) specifically, taking full advantage of the platform features; or, if Web technologies like HTML5, CSS or JavaScript, should be used which are more platform independent. This is true in theory at least because there are still differences in browsers, which relates to the underlying platform, too. A third possibility is to implement hybrid apps. At their core Web technologies are used, which are then embedded in a wrapper to make the app behave like a native app. Such a hybrid app will work on the host platform and related app store just as any other native app.

Clearly, covering various platforms increases the reach of an app and may also help to cover different types of customers since different platforms attract different users. That, however, also means more development and maintenance efforts. Tools can help develop an app that can be run on various platforms out of one code base — such as Appcelerator, Cordova/PhoneGap, Marmalade, Xamarin, just to name a few. They all have different approaches and differ in which platforms they cover.

Regardless of the final technical platform of choice, every platform has its specialties and specific language idioms that need to be understood to fully leverage the platform. The app lifecycle – a very common concept across all mobile platforms but certainly different to conventional desktop software – and how to handle it needs to be understood and addressed in a platform-specific way.

Every platform has a specific programming language, which also has particular idioms. In case of Android the programming language is Java. One unique idiom is the concept of Intents in Android. Intents are a communication mechanism that allow asynchronous messaging between Android apps, between an app and the operating system, and between components within an app.

These platform specific idioms need to be understood in software engineering for mobile.

Android lifecycle and intents, 3scale

In this part, I discussed the importance of making the right technical platform choice and its implications. In the next part of our series The Five Elements Of Software Engineering For Mobile (Part 3) I will cover how to get the UX right.