C#移动开发：跨平台指南

需积分: 16 199 浏览量更新于2024-07-28 收藏 5.83MB PDF 举报

"使用C#进行移动应用开发，涵盖了苹果iOS、安卓Android、Windows Phone (WP)和塞班Symbian平台的开发知识。" 在移动应用开发领域，C#是一种非常强大且灵活的编程语言，它允许开发者创建跨平台的应用程序。这本书《Mobile Development with C#》由Greg Shackles撰写，提供了全面的指导，教你如何利用C#技术来构建适用于不同操作系统（iOS、Android、WP和Symbian）的手机应用。 1. **C#语言基础**：C#是一种面向对象的语言，具有丰富的特性和强大的类型系统。学习C#的基础语法、类、对象、接口、继承、多态等概念是开发移动应用的第一步。此外，理解C#中的异步编程模型，如async/await关键字，对于处理耗时操作（如网络请求）至关重要。 2. **.NET Framework与Mono**：C#的移动开发通常基于.NET Framework或跨平台的Mono框架。Mono提供了在非Windows平台上运行C#代码的能力，使得开发者能够在iOS、Android上使用C#。 3. **Xamarin**：Xamarin是Microsoft收购的一个工具集，它极大地扩展了C#在移动开发中的应用。通过Xamarin，开发者可以使用单一的C#代码库创建原生的iOS、Android和Windows Phone应用。Xamarin.Forms是一个UI框架，它允许开发者编写一次代码，跨多个平台渲染UI。 4. **iOS开发**：使用C#开发iOS应用通常涉及Xamarin.iOS。开发者需要了解iOS的界面设计原则，如Storyboard、Auto Layout以及Objective-C/Swift的交互，尽管大部分工作可以在C#中完成。 5. **Android开发**：Xamarin.Android提供了在Android平台上开发的接口。开发者需要熟悉Android的组件（如Activity、Intent和服务）、资源管理和权限控制，同时利用C#的特性来提升开发效率。 6. **Windows Phone开发**：对于Windows Phone平台，C#是首选的开发语言，通常配合XAML进行UI设计。理解Silverlight和Universal Windows Platform (UWP)的概念对开发WP应用很有帮助。 7. **塞班Symbian开发**：虽然现在Symbian市场已不如从前，但C#依然可以通过 Carbide.C++ 和诺基亚的Qt框架进行Symbian应用开发。开发者需要学习Symbian的API和系统架构。 8. **调试和测试**：跨平台开发需要在多种设备和模拟器上进行测试。Xamarin提供了一套强大的调试工具，帮助开发者定位并修复问题。 9. **性能优化**：跨平台开发可能面临性能挑战，优化代码、减少内存占用和提高响应速度是关键。了解每个平台的性能特性，如垃圾回收机制、内存管理策略等，可以帮助提升应用性能。 10. **发布和分发**：最后，开发者需要了解各个平台的发布流程，包括应用商店的政策、版本控制、更新策略和用户反馈处理。《Mobile Development with C#》这本书将引导读者深入了解如何利用C#这个强大的语言进行多平台的移动应用开发，涵盖从基础到高级的各个方面，无论你是新手还是有经验的开发者，都能从中受益。

Android

Since Google purchased it in 2005 and began releasing versions in 2008, Android has

taken the smartphone market by storm. Just a few years and numerous versions after

its initial release, as of February 2012, Android accounts for just over 50% of the US

smartphone market, a number that continues to climb every month (http://www.com

score.com/Press_Events/Press_Releases/2012/4/comScore_Reports_February_2012_U

.S._Mobile_Subscriber_Market_Share). Most of Android is open source and licensed in

a way that gives hardware vendors a lot of flexibility, so the ecosystem of Android

phones is very diverse. Because of that flexibility, many vendors make significant

changes to the versions of Android that ship on their devices, so very few devices are

actually running a stock version of the operating system. With the release of Honey-

comb, Android has also started to stake its claim in the tablet market as well. Addi-

tionally, Android can be found in Google’s television platform, Google TV, as well

devices such as Barnes & Noble’s Nook Color and Amazon’s Kindle Fire, which bring

the richness of tablets to the world of e-readers. Ice Cream Sandwich, the version of

Android following Honeycomb, aims to help bridge the growing divide between An-

droid smartphones and tablets.

Windows Phone

In 2010, Microsoft released Windows Phone 7, which marked a long-overdue shift

away from its legacy Windows Mobile platform that had long since stagnated. The user

interface in Windows Phone 7, dubbed Metro, is decidedly unlike the approach taken

by both iOS and Android. A strong emphasis is placed on simplicity, typography, and

expansive interfaces that aim to provide a sense of depth and a natural user experience.

Device vendors are given a small amount of freedom in designing their devices, but

Microsoft maintains a strict set of requirements they have to meet in order to ensure

stability and quality, as well as avoid some of the fragmentation problems seen in the

Android realm. While the platform is still in the very early stages of its life, Microsoft

seems dedicated to pushing the platform forward to try and gain back some of the

market share the company has lost over the years. In late 2011, Microsoft shipped the

Windows Phone 7.5 update, codenamed Mango, which started to bring in many fea-

tures missing from the first releases, such as local databases and camera access.

Write Once, Run Anywhere

iOS, Android, and Windows Phone, despite the fact that they are all mobile platforms,

have very distinct ways of doing things and their own required languages in which to

do them. iOS applications are written in Objective-C, while Android makes use of Java.

Windows Phone leverages the .NET Framework, where the primary languages are C#

and Visual Basic .NET. You can also use C and C++ on iOS and Android, but they are

not currently supported on Windows Phone (see Table 1-1). As developers, we dread

2 | Chapter 1: Surveying the Landscape

the idea of having to repeat all of our work three times in three different programming

languages. Aside from the upfront overhead of doing the work three times, bug fixes

found later on will also likely have to be fixed three times. For any non-trivial

application, the technical debt can add up quickly, so the natural response is to seek

out some sort of cross-platform solution to minimize the cost of building and main-

taining applications for these devices.

Table 1-1. Native platform languages

iOS Android Windows Phone

C / C++ X X

Objective-C X

Java X

C# X

Visual Basic .NET X

The promise of a “write once, run anywhere” solution is nothing new in the develop-

ment world. It tends to come around whenever there’s a need to publish applications

on multiple platforms, whether on the desktop or on mobile devices. The mantra was

originally coined by Sun when it was pushing for Java to be the unifying language for

all platforms and devices. The concept is certainly not unique to Java, though, nor was

that the first time such a solution was proposed.

It has a natural appeal to us as developers. Who wouldn’t want a silver bullet like that

at our disposal? We could write everything once, get it just the way we want it, and

then instantly be able to target users on all platforms. Unfortunately, things that seem

too good to be true often are; there’s a reason why Java, over a decade and a half into

its life, has yet to become the common language for developing cross-platform desktop

applications. I think Nat Friedman, CEO of Xamarin, put it best in an interview he did

on the .NET Rocks! podcast:

“‘Write once, run anywhere perfectly’ is a unicorn.”

Now, let me take a step back for just a moment to provide some clarification here. I

don’t intend for anything in this chapter, or this book for that matter, to be taken as a

slight against frameworks that decided to take this approach to solving the problem.

The silver bullet trap works in both directions. No matter the context, there is never a

solution so perfect that it solves all problems. Instead, what I will outline in this book

is meant to demonstrate only one approach to solving things. It’s another set of tools

for your developer tool belt.

Having said that, let’s take a moment to think about who stands to benefit the most

from the “write once, run anywhere” method. You could make the argument that the

user benefits from you being quicker to market or supporting his platform, and though

there is some legitimacy to that, I would tend to disagree. Instead, when all is said and

done, it is we, the developers, who really benefit by cutting down the amount of time

Write Once, Run Anywhere | 3

it takes to write and publish our applications. However, this reduced development time

often involves making concessions that sacrifice user experience. Each platform has its

own hardware configurations, with varying screen sizes, resolutions, and buttons. Each

has its own set of user interaction metaphors and guidelines for how an application

should look and behave. In order for your application to look and feel native, it should

act like the other applications on that platform.

Writing to the lowest common denominator can end up making your application feel

foreign to all of them. Applications on Windows Phone are designed to look and behave

differently than those on iOS, and that is something that should be embraced rather

than glossed over or abstracted away. The experience you present to your users should

be the primary concern when designing your application’s interface. Ultimately, that

is what will set your application apart from others who take shortcuts along the way.

By now, you’re probably thinking to yourself, “So if I’m not writing in the platform’s

native language, and I’m not leveraging one of these cross-platform frameworks, how

do you expect me to write my applications?”

An Alternative Approach

What I am going to propose is an alternative approach where you can leverage the

power of the .NET Framework, along with the powerful C# language, across all three

platforms. While this may sound similar to “write once, run anywhere,” the key dif-

ference is that C# and the Base Class Libraries are used as a universal language and

library where the device-specific and user interface-specific elements are not abstracted,

but are instead exposed to developers. This means that developers build native appli-

cations using three different user interface programming models, one for each platform,

while using C# across the board.

As mentioned earlier, .NET is exposed natively on Windows Phone, so there’s no fric-

tion there. However, we know that on both iOS and Android it is not, so how can we

make this work? To help bridge this gap, a company named Xamarin has created two

products, MonoTouch and Mono for Android. We will explore these products in more

depth in later chapters, but the elevator pitch is that they allow for writing native

applications in C# (see Table 1-2), providing bindings to the platform’s native libraries

and toolkits so that you’re targeting the same classes you would in Objective-C for iOS

or Java for Android. Because you’re working against the platform’s native user interface

toolkits, you don’t need to worry about how to make your application look and feel

native to the platform, since it already is.

Table 1-2. Native platform languages with Mono tools

iOS Android Windows Phone

C / C++ X X

Objective-C X

4 | Chapter 1: Surveying the Landscape

iOS Android Windows Phone

Java X

C# X X X

Visual Basic .NET X

Apple is known for being strict about what gets into the App Store, so

you might be wondering whether it will only accept applications written

natively in Objective-C. There are actually thousands of MonoTouch

applications in the store. In fact, iCircuit, a MonoTouch application,

was shipped with their demo iPad 2 units that were sent out to stores.

As the names imply, MonoTouch and Mono for Android expose .NET on iOS and

Android by leveraging Mono, an open-source, cross-platform implementation of the

Common Language Infrastructure (CLI), an ISO standard that describes the virtual

execution environment that is used by C#. Despite the fact that they are commercial

products, both offer free evaluation versions that do not expire, and allow you to deploy

to the iOS simulator or the Android emulator. There is no risk in taking them out for

a spin. In the next chapter, we will explore how to get started with these tools, and

build your first application along the way.

Apple and Google release new versions regularly, so you might be won-

dering

what that means for you if you’re using MonoTouch or Mono

for Android. Generally, there is no waiting period here, as both products

track the beta programs for iOS and Android. For example, MonoTouch

typically releases the bindings for a new operating system within 24

hours of the official Apple release. In addition to the quick release cycle,

Xamarin offers first-class support for its products, providing prompt

responses through mailing lists and IRC, and maintaining thorough,

user-friendly documentation. Even outside of Xamarin, the Mono com-

munity in general is very active and helpful as well. You can find

information about the company and products at http://www.xamarin

.com/.

If you’re already a .NET developer, you can immediately hit the ground running, still

having the familiar namespaces and classes in the Base Class Library at your disposal.

Since the Mono Framework is being used to run your code, you don’t need to worry

about whether Objective-C or Java implements a particular C# feature you want to

use. That means you get things like generics, LINQ to Objects, LINQ to XML, events,

lambda expressions, reflection, garbage collection, thread pooling, and asynchronous

programming features. Taking things even further, you can often leverage many exist-

ing third-party .NET libraries in your applications as well. You can turn your focus

An Alternative Approach | 5

towards solving the business problem at hand instead of learning and fighting yet

another set of new languages.

As great as this is, the bigger win with this approach is the ability to share a large

percentage of your core application code across all platforms. The key to making the

most out of this is to structure your applications in such a way that you extract your

core business logic into a separate layer, independent of any particular user interface,

and reference that across platforms. By doing so, each application essentially becomes

a native user interface layer on top of that shared layer, so you get all the benefits of a

native user experience without having to rewrite the application’s main functionality

every time (see Table 1-3). In Chapter 3, we will explore some techniques available to

help keep as much code as possible in this shared layer and maximize code reuse across

platforms.

Table 1-3. Application layers

iOS Android Windows Phone

Runtime Mono Mono .NET

Business logic C# C# C#

User interface MonoTouch Mono for Android Silverlight

The classes and methods exposed by a framework make up what is referred to as its

profile. The .NET profile exposed by both MonoTouch and Mono for Android is based

on the Mono Mobile profile. The mobile profile is a version of the .NET 4.0 API that

has some of the desktop and server features removed for the sake of running on small

embedded devices, such as the System.Configuration namespace. This profile is very

similar to the core of Silverlight, which is also a subset of the full .NET profile for the

same reasons. Since Windows Phone is also based on Silverlight, there is a large amount

of overlap between all three of these profiles, meaning that non-user interface code you

write for one platform is very likely to be compatible with the other two.

Technically, the Windows Phone platform supports developing appli-

cations

using both the Silverlight and XNA frameworks. Since XNA is

more suited for game development, this book will focus on building

applications with Silverlight. By definition, games define their own user

interfaces, so not all of the problems outlined earlier with regards to

providing a quality cross-platform user experience will necessarily apply

when developing games.

The MonoGame project provides an XNA 2D implementation that runs

on both MonoTouch and Mono for Android. This is a third-party com-

munity project that is continuously evolving. More information about

the MonoGame project can be found at

http://github.com/mono/MonoGame.

6 | Chapter 1: Surveying the Landscape

剩余171页未读，继续阅读

kamilzhang

粉丝: 1
资源: 5

C#移动开发：跨平台指南

Windows Mobile 5.0上的C# GPS应用开发教程

使用C#开发移动应用：超越Windows Phone

Windows Mobile应用开发步骤详解

C#开发Android应用实战

c# 《Windows Mobile平台应用与开发》源码

详解C#开发Android应用程序的流程

C#移动开发 [Mobile Development with C#]

C#+Mapx Mobile开发Demo

C#与Arcgis Mobile的开发

C#windows mobile计算器

最新资源