Introduction to bada: A Developer's Guide

By Ben Morris, Manfred Bortenschlager, Cheng Luo and 2 more

An expert introduction to Samsung's new mobile platform

Bada is a new platform that runs on mass market phones and enables you to build cutting-edge applications for mobile devices. As an access layer, bada has all the advantages of native coding and provides the power of multi-tasking and multi-threading. This book serves as a complete introduction to the exciting capabilities of bada and shows you how bada offers commerce and business services with server-side support. The authors walk you through the complete set of platform APIs and detail the architecture of bada. Code fragments are featured throughout the book as well as examples that utilize all of the major APIs, from sensors to maps and from phonebook to billing.

• Introduces Samsung's new platform, bada
• Explains the bada framework, its APIs, and the bada architecture
• Walks you through how bada is a logically structured mobile platform that allows you to build exciting apps for mobile devices
• Features code fragments and numerous examples that address all the major APIs

Discover how bada boasts the richest set of end-to-end service, commerce, and billing APIs with this book!

• Language: English
• Publisher: Wiley
• Release date: Oct 1, 2010
• ISBN: 9780470977385

Book preview

Introduction

This book is for developers. It will get you up and running with your first bada app, quickly. Looking beyond your first app, we hope this book will find a permanent place on your desk as a bada companion, with its overviews of the platform, the bada architecture, bada namespaces, application programming interfaces (APIs), and services – and above all with its recipes. These have been written by Samsung’s bada development team to give you more than 45 best-practice examples of common bada APIs in use. You can learn from this code, and you can reuse this code.

As for the goal of this book, we hope it’s clear – to introduce you to bada, and to make it as easy as possible to develop cool apps for bada phones.

Overview of the Book

Developing for mobile is never trivial, whatever the platform. In Part 1 of the book, Chapter 1 runs through the issues that can bite you in mobile development. If you are a seasoned mobile developer, you may know the issues already. However, the boom in mobile app development has brought thousands of new developers into what used to be a niche market. If you are not one of those grizzled types who cut their baby teeth on embedded, eating ARM[1] assembler for breakfast way back at the dawn of mobile, then this could be for you. Understanding the mobile difference, and becoming comfortable with it, is the essential starting point for doing mobile development. And if it helps, Chapter 1 also summarises some agile best-practice. Rules are good for breaking, as well as following, but in either case it’s good to know what they are.

Chapter 2 and Chapter 3 show you just how easy it is to get started with bada, introducing the Eclipse-based development environment (IDE) and its Application Wizard to work up an example from bare-bones to first demo user interface (UI). Other topics covered include app deployment, and the bada developer portal, which provides the interface to app publishing through the Samsung Apps mobile store.

Chapter 4 moves on to explore the bada platform architecture, and to introduce some important bada concepts – including bada’s C++ namespaces, class library, security/protection model, and programming idioms.

Chapter 5 introduces bada services, one of bada’s exciting innovations, which integrate APIs for commerce, social networking, and other service-centric features, with the platform APIs. This makes it easy to integrate services into your apps to stretch the boundaries of what users can do on mobile.

NOTE: At the time of writing, some of these services are still restricted to partner developers, so keep an eye on breaking news on developer.bada.com as the developer story continues to unfold.

To conclude Part 1 of the book, Chapter 6 provides an overview of each of the bada namespaces, highlighting the most important classes.

Part 2 of the book presents a collection of recipes, organised into groups that show off the main bada features and provide you with ready-made code solutions to integrate into your own projects.

What bada Is – and Isn’t

bada (with a small b) is a new open smartphone platform for Samsung mass-market mobile phones. ‘Open’ means that phones that ship with the bada platform are open to third-party developers, to create and publish native applications to phone users through the Samsung Apps application store.

The vision of bada is that it is a ‘Smartphone for Everyone’. bada was created to provide a smartphone experience for more people. So, the major target customers for bada phones are not only techy early adopters, but also high school students. In a similar way, bada is not just targeted at existing geographical markets for smartphones but at developing markets too. To achieve this, bada is designed to provide powerful features while it supports a high level of configurability for a variety of hardware – from affordable to expensive and powerful.

bada’s origins are in Samsung’s proprietary platform, which was first used in 2004. Since then, it has been adopted widely for handsets and is used by numerous customers. For this reason, the proprietary platform has been successfully customised for a wide range of hardware as well as kernels. bada exploits the experience and knowledge gained throughout the history of Samsung’s mobile platform. Well-proven concepts are re-used supplemented with new insights and improvements. bada is highly configurable over various hardware configurations and kernels. For example, the first bada phone, Wave, is very high end with a 1 GHz CPU and a variety of sensors, while some of the later phones use less powerful hardware but are affordable to the mass market. Such configurability for a wide range of devices will make bada the best platform for mass-market phones.

Another noteworthy bada feature is the integration of service APIs into the platform. Services include social networking, buddy lists that allow users to share real-time information with their friends, shopping and commerce APIs, location and points of interest, and even weather services. All are included out-of-the box and can be integrated into any third-party application (but note the current restrictions on access to non-partner developers).

It’s worth emphasising that while bada is a new platform, much of the system underneath it (middleware and below) effectively re-uses enhanced version of components of Samsung’s proprietary platform.

If the significance of that fact escapes you, think of it like this – Samsung shipped some 40 million phones a year in the touch-phone category in 2009. These are the phones that have made Samsung the global number-two handset vendor, pushing strongly to become global number-one. While bada won’t open the box on previously shipped phones, it opens the box on the next tens-of-millions of phones that Samsung will ship in this category this year, extending to perhaps hundreds-of-millions over the next few years.[2] This means that bada brings the mid-range, touch-phone category into your reach as an app developer, with a ready-made global audience, a proven middleware architecture, the proven touch-based UI, and potentially huge device numbers.

And if you want to get a hands-on feel for what you can do with that, go into your local phone shop and play with the Samsung Wave (the first bada phone to ship). It makes for a compelling story.

Just the Facts

bada is designed for simplicity. bada offers a small but carefully chosen set of APIs that enable app developers to create simple but powerful applications.

Remember, bada apps are not aimed at power users, but at the mass market of ordinary users, using their phones to get everyday tasks done, to keep in touch with friends, and to browse, buy, and have fun in between.

bada is More Than Just Another Smartphone OS

bada contains a C++ class library as a framework layer, two more layers that provide features for controlling the device and accessing services, and a mobile operating system (OS) kernel. The bada API nicely abstracts from these layers and opens up the various functionalities to developers.

bada is therefore (strictly speaking) not a mobile OS at all. Rather, it is a platform that includes the enhanced version of selected components of Samsung’s proprietary (and proven) middleware with a clean and well-structured C++ class library, supported by a commercial, mobile RTOS kernel.

bada is Open

bada APIs are open to all.

bada ships a free SDK, with open and free developer sign-up, and with publishing that is open to all via the Samsung Apps store.

No, that doesn’t mean that bada is open-source – it just means that bada phones are open to third-party software, and any developer can be a third-party.

At the time of writing, not every bada API is open to third-party developers; and in fact, some of the most interesting APIs are open only to partner developers. But this is an evolving position. In time, restrictions will be relaxed to make bada even more open when compared to other mobile platforms.

bada is Native

bada is written in C++ on top of C/C++ middleware, and bada apps are written in C++.

bada apps run in a native OS process, with access to native OS threading.

bada also supports Flash and WebKit runtimes, and integrates Flash and WebKit support into its native APIs allowing inter-operation and multiple language code.

bada is Neat

bada introduces some new, cool, network-based service APIs and integrates them seamlessly into the platform. These include buddy and social networking, location, and commerce and store APIs, which all interact with the bada Server to enable your app to track and exchange – for example – location data, including retrieving landmarks based on mobile location, and to swap instant messages and location data with the user’s buddies. You can set up an online store and use bada’s commerce APIs to interface your app with your store.

Note: At the time of writing, these APIs are restricted to partner developers.

bada is Easy

Within reason. Native bada development is in C++, and arguably C++ is never easy. But bada does a good job of abstracting most of the complexity into its frameworks, where developers are insulated from it.

bada makes good use of namespaces, is well-organised, and avoids the temptation of some complex features of C++. For example, templates are used very sparingly, and where they are used, they are used to good effect.

bada is Buzzword Compliant

bada supports more buzzwords than we even want to try to list! Check out developer.bada.com.

[1]The ARM RISC processor architecture, from UK company ARM Ltd, is overwhelmingly the most popular CPU choice for mobile hardware.

[2]For example, see web reports that quote Samsung estimates of 15 million bada phones shipping in 2010, and over 50 million in 2011, available from http://bit.ly/bNYBkG.

Part I: About bada

Chapter 1: The Mobile Difference

Mobile is different. This chapter summarises what makes mobile software and development different from developing ‘conventional’ fixed software for desktops or web applications. We also suggest some software development best-practices that are particularly appropriate for mobile, and that can help you stay in control of your project.

1.1 The Mobile Context

Some 20 years on from the birth of mobile, hardware and telecoms have changed out of all recognition. In all sorts of ways, mobile usage has also changed the way that people behave. Even so, the exploitation of mobile services has hardly begun. The apps revolution of the last several years, dominated by iPhone but certainly not limited to it, is a clear indicator of things to come. The real revolution, however, will be the arrival of apps and services for the mass market – and that’s what makes bada a potential game changer.

From a practical perspective, the bada platform and accompanying ecosystem provide a great foundation for mobile development. So what makes mobile different?

First, mobile hardware is different from desktop hardware. It’s not just that mobile phones fit in your pocket. The relentless drive to fit more and more functionality into smaller and smaller physical packages has led to almost continuous innovation. In consequence, mobile storage, mobile display, and mobile power technologies are different from their big brothers on the desktop. When you are developing for mobile, it is essential to understand how these differences can impact the way you design your apps and the way you write your code.

Second, mobile usage is different. Users use mobile differently from the way they use fixed desktop devices, and they consume mobile services differently. Even the way that users buy and pay for their mobiles and mobile software is quite different from what happens on the desktop. In fact this is a crucial difference, because without the willingness of users to casually buy mobile software, there would be no apps revolution! Again, these are differences that will impact the way you design your apps and write your code.

Above all, however, the mobile opportunity is different. Let’s illustrate that difference with an example – mobile services. We can divide these into two groups: new services that are only meaningful in a mobile context, and others that are traditionally used in fixed or web browser-based environments but that can now be extended to the mobile dimension.

Location-based or map services are good examples of the first group. The idea of location-based services (LBS) has been around for over a decade now. Few would doubt the potential of such services to add unique value on mobile, where services and information can be delivered filtered for specific locations, providing information that is related to a user’s current position and that addresses an immediate need. However, only a few such services have turned out to be really big hits, and the most obviously successful example – in-car navigation – isn’t network based at all, and so delivers almost nothing of the real promise of LBS. The reason is simple. In the past, the technologies and ecosystem just were not ready. Today, however, everything is in place for LBS finally to deliver its promise.

Examples of the second group are the booming social network services (SNS) stemming from the Web 2.0 movement that gave birth to blogs, Facebook, MySpace, YouTube, Twitter – you name it. Such applications and social networks can now increasingly be invoked and used from mobile handsets, either through web sites customised for mobile browsers or through standalone apps. But in these cases too the new dimensions that mobile brings have barely begun to be exploited.

These examples also point to another difference between mobile apps and desktop applications. On the desktop, your word-processor or spreadsheet or database application, and your first-person shooter or adventure game, are big and complex, and the bigger they are, the better; they do everything, integrate with everything, and each would be very happy if it was the only application you ever needed. Mobile apps are almost exactly the opposite of this – they are small and focused pieces of software, designed to do one thing, and do it well.

The most successful mobile software respects the specific characteristics of mobile, including hardware constraints, different ecosystem structures (for example, shorter product lifetimes, but also shorter time to market), and the different usage context that dictates a different style of user experience. Ideally, whatever its application area, mobile software adds value by directly addressing a specific user need or by improving the mobile experience for the user – in terms of cost, effort, or time savings, increased flexibility, improved means of communication, or just more fun.

1.2 Characteristics of Mobile Software

Mobile software has a number of characteristics that make it very different from desktop or web-based software, the most important being:

1. technological differences;

2. differences related to usability and user experiences;

3. differences in the ecosystem.

In the following sections we touch on each of these topics in more detail.

1.2.1 Technological Differences

Mobile handsets are getting steadily more powerful, with processor speeds of up to 1 GHz, multi-gigabyte memory and removeable memory of 32 GB or more now becoming common on high-end devices. Advances in display technology have also enhanced the user experience. The latest display technologies such as Samsung’s Super AMOLED[1] deliver vastly better contrast, more efficient energy consumption and less sunlight reflection than older mobile displays.

As network connections get faster, the services available to users have grown to include rich multimedia streaming and games, while user confidence in increased connection security has led to an explosion in mobile eCommerce and eTicketing apps.

But it’s the advances in positioning technologies that have led to the biggest revolution in mobile apps. GPS[2] is now standard even in low-end devices and bada offers developers an easy and powerful way to develop location-aware apps through its APIs for location services.

Advances in hardware provide new development possibilities. For example, sensor hardware has become commonplace on phones, which now include accelerometers, electronic compasses, and light sensors. Sensors provide functionality not available to fixed, desktop applications, for example tilt and shake user interaction with apps.

Developing for mobile devices also provides some challenges to those used to creating desktop or web applications. Mobile hardware is improving rapidly, but compared to the desktop or to a typical server, phones are much less powerful with much less storage. On mobile, network connection is intermittent by design, compared to always-on Internet connections on the desktop. The way that the user interacts with a mobile device is also different; a smaller, touch screen and virtual keyboard input cannot offer the same experience as a full-sized keyboard and mouse.

The most important, and often overlooked, difference in mobile compared to desktop development is energy consumption and the dependence on the battery. Battery capacity on mobile devices has increased, but so have the range of technologies that consume a lot of energy: GPS, Wi-Fi, Bluetooth, 3G, and multimedia support are prime examples, and some currently successful phones do not even make it through the day without needing recharging, and battery life is a frequent user complaint.

Device manufacturers are doing their best to improve battery life, but software developers have their part to play through careful use of resources. Because mobile phones typically run for days or weeks or longer without being switched off, memory leaks, for instance, can seriously compromise the phone’s performance.

1.2.2 Differences Related to Usability and User Experiences

New mobile technologies such as sensors and touch screens allow us to build better UIs and to represent information in more user-friendly and usable ways. In particular, Web 2.0 applications such as Facebook and Twitter can all now be accessed easily by mobile users using web pages designed for access on-the-go or by applications.

Users may be able to do more with their devices, but they are still confronted with a huge range of different screen sizes, input methods, and UI ‘look and feel’ approaches that can make using mobile applications a frustrating experience. Developers who follow user interface guidelines, such as those provided by bada, will create easy-to-use, consistent applications on a particular platform, but there are still many platforms available. Several initiatives such as bada, the LiMo foundation, the Open Handset Alliance, and the Symbian Foundation show a trend towards open systems to facilitate harmonisation and the easing of application development and deployment. However, mobile developers will have to deal with the problem of incompatible platforms for some time to come.

Mobile applications are also used differently from their desktop equivalents. If you are mobile and want to find information about what is showing at the local cinema, or a review of a particular restaurant, you want to find that specific information quickly and don’t want to spend time searching through information you don’t need. Your attention span for using the application is limited, so you want to be presented with location-specific information. You might also be trying to find directions, using the mobile in sunlight, or somewhere with a lot of background noise, all environmental factors that need to be considered.

1.2.3 Differences in the Ecosystem

Users expect to be able to find and download the software they want using their device when they’re on the move. Users should be served following a wish and use notion. When users wish to satisfy a current need they should be able to get and use corresponding information or services as fast and simply as possible. They want the purchasing and installation process to be simple, which is where a central one-stop-shop such as the Samsung Apps store comes in. Developers distribute their applications via Samsung Apps, one central location from which users of bada devices can purchase and download apps and make in-app purchases. One side-effect of this approach is that the network operator no longer plays the ‘gatekeeper’ role to their devices; the user can freely decide which apps to install.

The lifetime and the time to market of a mobile app are substantially shorter than traditional software products and developers need to adapt. By having a central distribution system such as Samsung Apps, the developer can concentrate on creating and marketing their application in the knowledge that the distribution, purchasing, and revenue sharing model will be taken care of by the Samsung Apps store.

This simplified model of application distribution also has other advantages. Users can be sure that applications will be independently tested and comply with a certain quality standard, will respect the integrity of the user’s data, and won’t spend their money on phone and data calls without asking.

A further positive side-effect of the app store model is that costs for users become much more transparent. Network operators have recognised this trend and come up with contract bundles with flat data rates or volume packages in order to encourage the download of apps from stores. In the past, complex and non-transparent cost models discouraged users from using mobile services or downloading mobile apps because they feared exaggerated costs. With new all-inclusive pricing, downloading apps and invoking mobile services has become much more user-friendly and thus accepted.

The bada platform in combination with Samsung Apps represents an ecosystem that addresses, exploits, and, in fact, shapes some of the differences that we have outlined in this chapter. Figure 1.1 summarises what the bada ecosystem stands for.

974018-fg0101.eps

Figure 1.1 The bada ecosystem.

At one end of the chain are the developers or application providers who want to develop applications. At the other end are the users or customers who want to use mobile apps. Along this chain Samsung provides three core building blocks that foster the bada ecosystem. Central to it is the bada platform, which is the execution environment deployed on mobile handsets. This platform not only covers the mobile part but also allows seamless access to the bada Server as you will find out later in Chapter 5. Powerful and well-abstracted APIs are exposed as an open SDK to developers. In addition to that, the left block in Figure 1.1 covers a large number and variety of technical support resources, such as training material, tutorials, sample code, tech blogs, videos, and the API reference documentation. The right block is the application store Samsung Apps that allows you to certify and publish your apps. Once your app is ready for publication, you can decide if – via the store – you want to sell your app or give it away for free, or however else you want to become rich and famous.

1.3 Mobile App Development Best-Practices

We argued that mobile apps have some specific characteristics that make them different from conventional software. Mobile markets are also different and develop at a faster pace. Hence, in order to create successful mobile solutions or applications, we recommend deploying some best-practices during development. In the appendix we provide an example of a full software engineering process for mobile applications.

Of course, you can follow any process you prefer or develop your software without following any process at all. There is a range, from strict waterfall model to cowboy coding. As a rule of thumb the more complex a project is and the more coordination it requires, the more formalisation is advisable in terms of processes. Experience has shown that so-called agile software development processes are very appropriate for fast-paced software, which mobile apps definitely are.

In the agile manifesto[3] software engineering experts have summarised the key factors that should help to produce better software faster and more reliably. They state that agile development is about focus on result. This means executable software should be built as soon as possible, which is the primary measure of progress. Software should be built incrementally starting from its core functions over various iterations. Tool and process support is relevant but must be appropriate to the solution in order to avoid unnecessary overhead. Finally software engineering is about people working together. Hence, communication – ideally in a face-to-face and spoken way – is at the core of agile development. This not only refers to the project team but also, and just as importantly, to the stakeholders, clients, and future end-users.

In line with this, we would like to add to this recommendation an emphasis on using as much prototyping and diverse testing as possible throughout the whole development, where both are integral parts of and inherently supported by the bada platform and its development tools. Prototypes can be exploited in nearly any phase during the development of mobile software solutions. They are primarily helpful for eliciting requirements or to get a common understanding with various stakeholders early in the project. Testing certainly is not unique to mobile software engineering but must be treated and executed differently in mobile development. This is an effect of various issues related to mobile software such as the heterogeneity of hardware and devices, the dependence on context factors that are difficult to test on simulators (e.g. geographic locations), and the phenomenon of the discrepancy between simulator and real device behaviour.

The bada toolset provides means to support both. First, the UI Builder, which is integrated into the bada IDE, allows building simple mock-up prototypes easily and quickly. Developers can use this WYSIWYG tool to create first ‘clickable’ demos by visually placing a variety of UI controls on the device screen.

A second convenient tool is the Event Injector that comes with the bada Simulator. This is useful for simulating a broad variety of context data. Incoming calls, text messages, and battery level can be tested, as well as location and sensors, including acceleration, tilt, compass, and proximity. It is always difficult to test mobile apps in a simulator because obviously you are missing all the context data, which is so necessary. By far the more expensive and complex type of test is deployment on real devices and test-runs in the real-world context. With the bada Event Injector (see Figure 1.2), a lot of this effort can be shifted to Simulator tests, making system tests less time consuming and cheaper.

974018-fg0102.tif

Figure 1.2 The bada Event Injector.

But let us return to the ideas postulated by the agile manifesto. Often, ‘agile’ is misused to describe everything that does not have clear rules or a process. We would rather call this ‘cowboy coding’. Agile cannot be equated to chaos, or lack of rules or discipline. Agile app development does propose following some simple maxims and recommendations.

So, let us describe some rules. We do so by listing a toolbox of some best-practices coming from various agile methodologies such as Scrum, Test-driven Development, eXtreme Programming, and Crystal. Again, the core cornerstones are focus on results, incremental iterations, appropriateness of the means, and communication. The following best-practice recommendations all deal with one or more of these cornerstones:

• Focus on results more than on processes. Every procedure or means that does not help to achieve the goal of the software project should be cut off. The more complex a project, the more tools, rules, and formalisms it will require.

• Plan your software development into cycles or iterations. Identify the core and most critical components and priorities, and start with the most important ones (‘first things first’).

• Be tolerant towards change (changing requirements and change requests). Avoid rigid or inflexible structures, processes, tools, or methods.

• Try to produce executable software at the end of every iteration.

• Treat each iteration as an increment to the final software product.

• Try to keep design and software simple. Have possible extensions in mind but focus on producing executable code at least at the end of each iteration (‘keep it short and simple – KISS’).

• Make use of early feedback from various stakeholders, such as your client or end-users. User acceptance tests could possibly be integrated into every iteration.

• In the early stages, even use paper and pen to sketch software designs or early prototypes.

• Make use of a test-oriented development where you write the test cases first, at least for core or critical code parts.

• Build and integrate tested parts frequently (e.g. daily).

• Set up communication channels such that close contact with client and end-users is possible.

• Try to have regular, frequent, and brief intra-team communication without a formal overhead (e.g. daily stand-up meetings).

• Establish and publish team and project rules – such as a communication etiquette or coding standards.

• Conduct code reviews or pair programming sessions for core or critical code parts.

• Make sure you have efficient knowledge transfer within the team but also to client and user. This may not always be applicable or sensible. Sometimes this knowledge transfer may also be unidirectional.

• Use visualisation for your communication. Use, for instance, a visible whiteboard accessible to everyone in the team for sketching the tasks or features, and development progress.

• Although some form of documentation is necessary, keep it to a minimum: only as much as is necessary. And beware of over-specification.

Again, please bear in mind that you do not have to stick to the mobile software engineering best-practices outlined here. This is simply advice and something you can stick to.

[1]AMOLED stands for active-matrix organic light-emitting diode.

[2]GPS stands for Global Positioning System, which enables ground positions to be calculated from satellite signals. GPS was originally developed by the US military and is maintained for civilian use by the US Government.

[3]See http://www.agilemanifesto.org/.

Chapter 2: bada Basics

This chapter gets straight down to the essentials of developing native bada applications in C++. We’ll see just how easy it is to get a first skeleton application up and running on the bada Simulator.

To start with, this little app doesn’t do much – think Hello World! But this is the code at the heart of every bada app, and as we’ll see in the next few chapters, bada makes it easy to build up from this basic skeleton to create a full-featured, native application.

Note: At the time of writing the SDK version is 1.0.0 beta3. Current SDKs install on Microsoft Windows only. It’s likely that bada will support other development options eventually, but nothing is currently announced. The Simulator launches from the Eclipse-based bada IDE, which is included in the SDK.

What You Will Learn

This chapter aims